I've been trying to get the SDK softdevice ble demos to work on a mbed board. I'm using pyOCD+linux. I can compile and flash elf (.out) files in gdb with 'load' and I can do some basic debugging. The LEDs blink and the uart produces output. However, I haven't had any luck getting anything that uses the softdevice or the even the led_radio demo to work. The led_radio demo never gets out of "while (NRF_RADIO->EVENTS_END == 0U)".
I did a full erase using the reset button on the mbed board and then flashed the 7.0.0 soft device. Using pyOCD and gdb it seems that the soft device ends up written to the device.
Next I want to load on of the SDK demos. The mbed mass storage flash code can't program hex files generated by gcc (it creates a fail.txt saying that the file is corrupt). flash_nrf51822.py:flashHex() writes to NVMC_ERASEALL, so it will clobber the s110_7.0.0.
So what I want to do (and the only remaining option) is to use gdb. But this doesn't work, when I try to load ble_app_beacon_s110_xxaa.out:
$ arm-none-eabi-gdb -x ~/gdb.remote ble_app_beacon_s110_xxaa.out
Reading symbols from /home/ctaylor/TimeSponge/nordic/nrf51_sdk_v6_0_0/nrf51822/Board/pca10001/s110/ble_app_beacon/gcc/_build/ble_app_beacon_s110_xxaa.out...done.
0x00015076 in ?? ()
(gdb) load
Loading section .text, size 0x1f74 lma 0x16000
Loading section .ARM.exidx, size 0x8 lma 0x17f74
Loading section .data, size 0x45c lma 0x17f7c
<hang>
pyOCD gdb_server:
python test/gdb_server.py -d debug
Welcome to the PyOCD GDB Server Beta Version
INFO:root:new board id detected: 107002161FE6E019E20F0F91
id => usbinfo | boardname
0 => MBED MBED CMSIS-DAP (0xd28, 0x204) [nrf51822]
DEBUG:root:init board <pyOCD.board.mbed_board.MbedBoard object at 0x7f7f21b301d0>
INFO:root:DAP SWD MODE initialised
INFO:root:IDCODE: 0xBB11477
INFO:root:4 hardware breakpoints, 0 literal comparators
DEBUG:root:fpb has been disabled
INFO:root:CPU core is Cortex-M0
INFO:root:GDB server started at port:3333
INFO:root:One client connected!
...
INFO:root:flashing 99288 bytes
DEBUG:root:write blocks aligned at 0x20000200, size: 0x200
[ ] 0%DEBUG:root:write blocks aligned at 0x20000200, size: 0x200
[ ] 0%DEBUG:root:write blocks aligned at 0x20000200, size: 0x200
...
[=================== ] 95%DEBUG:root:write blocks aligned at 0x20000200, size: 0x200
[=================== ] 95%DEBUG:root:write blocks aligned at 0x20000200, size: 0x1D8
[====================] 100%
DEBUG:root:fpb has been enabled
<hang>
Killing gdb_server.py is not enough, it fails to reconnect with a "DAP_CONNECT response error". I have to unplug/plug the mbed board to reconnect.
When I examine memory with gdb I find that the softdevice is gone, but I find a reset vector at 0x16000 as expected. It seems that the gdb 'load' command is also clobbering softdevice and maybe things hang when it tries to execute from an erased flash.
So how do I get gcc compiled softdevice code to load onto the mbed board from linux?
Ignoring the issues of flashing the soft device, it would seem that the easiest thing to do is to link the softdevice into the gcc created elf file and then let gcc do a full erase and program the entire part.
Fixing the gcc generated .hex files so it mbed will accept them is also a temporary workaround if someone knows the secret trick to do this?
FYI, with the STM parts and openocd or stlink gdbserver, the 'load' command only erases the pages it is going to program and does not erase the whole part.
