sd_softdevice_enable() under gdb causing reboots

[Jean-Louis Bonnaffé]

Hi,

I'm developing on a custom nrf51822-based board, and using the s110 softdevice, version 7.0.0. With JLinkGDBServer and the toolchain's gdb, I can debug softdevice-less applications normally.

Problems arise when I build my apps on top of s110. Running from flash is ok, but during GDB sessions, my device seems to be reset soon after the call to sd_softdevice_enable(), and my gdb breaks again on the main(). No such reset can be observed when running from flash.

In the s110 documentation, I can read, that after a successful call, "A portion of RAM will be unavailable". Can this issue be related to RAM mapping overlap, and is there a way to avoid this ?

Thanks,

[Asbjørn]

If the application breaks when you start the softdevice it's usually related to the clock source used by the softdevice. Are you configuring the 16 MHz in any way from your application?

[Jean-Louis Bonnaffé]

I'm setting the low frequency clock source and accuracy: SOFTDEVICE_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_RC_250_PPM_1000MS_CALIBRATION,false). No change to XTALFREQ.

[Asbjørn]

Ok, but do you elsewhere in your code adjust or configure the HFCLK directly without going through the appropriate softdevice calls?

You are also initially mentioning RAM settings, are you sure you're not accessing the RAM area controlled by the Softdevice? Compare you settings with what is stated in chapter 11.2 in the Softdevice specification.

[Jean-Louis Bonnaffé]

Answers in order : 1. there is no HFCLK adjustment in my code, but my LFCLK source was wrong, I had to change it to NRF_CLOCK_LFCLKSRC_XTAL_50_PPM. 2. thanks for the link, I checked it, and my RAM configuration is OK.

[Jean-Louis Bonnaffé]

Browsing the devzone brought up the answers :

• Ole Morten's comment has been quite instructive here:

No matter if you use GDB or Keil's debugger, you will not be able to keep the BLE link while you're halted on a breakpoint, or keep running softdevice code after having halted on a breakpoint. [...]

• Hung Bui also confirmed in this topic:

It's not possible to get back to a connection after you stop for a break point when debugging. The timing will not be correct after you resume, and most likely you will have a connection timeout from the peer device (which is not halted). [...]

• Also worth mentioning, this note from Øyvind about the PRIMASK register :

If you stop the execution somewhere in the application code e.g. by using a breakpoint, you can step forward from there if you set the PRIMASK CPU system register to 1 after hitting the breakpoint. You can do this in the "Registers" window in Keil while in debugging mode. [...]