Hi, > On Feb 13, 2017, at 11:00 PM, Marcos Scheeren <[email protected]> wrote: > > Hi, > > Last month I was having some issues loading the compiled code to the board > without OpenOCD or JLink, just using GDB extended-remote mode, that seems > to be solved now - Thanks Marko and Chris for the help! > > So, I edited the linker script to flash the board at address 0x0 (removed > the header offset) and then building the targets and loading the outputted > .elf file onto the board via GDB "load" command.
Ok. That should indeed work. > And it worked fine for the blinky app and the bletest app, I can even scan > the bletest when set as advertiser on my android phone so the ble stack > seems to be working fine too. The console over UART also works. > But couldn't get blecent or bleprph to work. Both fail. > (Still can't use GDB "restore" on extended-remote, gives me "Writing to > flash memory forbidden in this context" =/ ) Quick peek to gdb sources tells me that the memory region is marked as flash, and comment says that only allow writes during ‘load’ phase (which, technically, I guess would be correct). Check the output of ‘info mem’, and see if you can change the properties of it. Alternative would be to convert the binary blob into a ihex or srecord format. gdb can load these the same way as it can load elf. You can use objcopy to do that. Note that elf has location data, as do ihex and srecord. > > Here are my target settings: > newt target show > targets/my_blinky_sim > app=apps/blinky > bsp=@apache-mynewt-core/hw/bsp/native > build_profile=debug > targets/nrf51_blecent > app=@apache-mynewt-core/apps/blecent > bsp=@apache-mynewt-core/hw/bsp/nrf51dk-16kbram > build_profile=optimized > targets/nrf51_bleprph > app=@apache-mynewt-core/apps/bleprph > bsp=@apache-mynewt-core/hw/bsp/nrf51dk-16kbram > build_profile=optimized > targets/nrf51_bletest > app=@apache-mynewt-core/apps/bletest > bsp=@apache-mynewt-core/hw/bsp/nrf51dk-16kbram > build_profile=optimized > targets/nrf51_blinky > app=apps/blinky > bsp=@apache-mynewt-core/hw/bsp/nrf51dk-16kbram > build_profile=optimized > > (Build runs fine! no ram or flash errors.) > > > On the gdb console I got this: > "Program received signal SIGTRAP, Trace/breakpoint trap. > Reset_Handler () > at > repos/apache-mynewt-core/hw/bsp/nrf51dk-16kbram/src/arch/cortex_m0/gcc_startup_nrf51.s:140 > 140 MOVS R1, #NRF_POWER_RAMONx_RAMxON_ONMODE_Msk" > > > and over UART I got: > "0:Assert @ 0x10eeb > 0:Unhandled interrupt (2), exception sp 0x20000b68” > > > If I check the assertion error at 0x10eeb shown on the UART console above > it reads "<ble_hci_ram_pkg_init+42>: 0x003a0cbd" on GDB. My guess the system is out of heap. Check while in gdb: p/d sbrkBase-brk Hopefully there are things you can prune out. > > "$newt version" outputs "Apache Newt (incubating) version: 1.0.0.b2" > > > If I try to run it step by step, somewhere in the execution it shows > "OS_INVALID_PARM" and “OS_MEM_NOT_ALIGNED" Line number data gets a bit muddy when compiling with optimizer on. So you’re probably not actually returning with those values. > Also, tried to run on previous tags (changed both newt tool and mynewt > core, new mynewt project dir) like mynewt_1_0_0_b1_tag, same "Unhandled > interrupt (2)" error for both bleprph and blecent. > > > Any thoughts why bletest works and other apps doesn't? Any other useful > information I could provide? Could it be related to unaligned memory blocks > due to the modified linker script? Highly unlikely that the linker scripts would cause this. I suspect it’s the RAM usage. Let me know how it goes, M
