How can I debug a softdevice application?

[Guest]

When I'm running a BLE application with the debugger, and the CPU halts on a breakpoint, it seems to end up in the assert handler when I start it again. How can I avoid that?

[Ole Morten]

You are right that when you start the CPU after having been halted on a breakpoint, you'll most likely either see an assert or hang in an infinite loop.

The reason is simply that the nRF51822 only have a single processor, so both the application and the softdevice's BLE stack will be halted when the device halts on a breakpoint. It is therefore not possible for the softdevice to receive or transmit BLE packages while halted, and this means that BLE link will be considered lost after the connection supervision timeout. Also, all stack events and hardware interrupts occurring will not be received properly while halted, so if you start running again, the internal sanity checks in the softdevice will therefore most likely fail, causing an assert.

You therefore have to do debugging by other means when using the softdevice, for example by doing UART printouts, toggling GPIO or similar. Please also note that it's perfectly possible to halt the CPU on a certain condition and look at the current state of variables and similar, it's only if you try to start again that you will see problems.

[Ole Morten]

Please also take a look at Øyvind's answer here: https://devzone.nordicsemi.com/index.php/can-i-debug-ble-program

[awneil]

That link is now broken - is the answer still available?

[Amanda Hsieh]

I think the link might be updated as https://devzone.nordicsemi.com/f/nordic-q-a/477/can-i-debug-ble-program