sd_softdevice_enable() crashes on nRF52832 when debugging

[Fabi]

Hi Everybody

When I run my code with the debugger, it always crashes when executing sd_softdevice_enable(). Even if there is no breakpoint activated. However, when I run the code without the debugger, it works fine.

I am using the PCA10040 dev board together with VisaulGDB for VisualStudio. The SDK is 12.2.0 togehter with the S132_nrf52_3.0.0 softdevice.

Does anybody have any idea?

Thanks

[bjorn-spockeli]

How do you know that the nRF52832 crashed when executing sd_softdevice_enable() if you're not using breakpoints? Once you've enabled the SoftDevice you cannot halt the program as this will break the timing requirements of the SoftDevice and it will Hardfault.

[Fabi]

I just run the solution without any breakpoint and get a 'SIGTRAP: Trace/breakpoint trap' error in Visual Studio. By placing breakpoints I could figure out that the error occures when executing sd_softdevice_enable(). Because every breakpoint before the execution of this function can be executed, all after this call can not.

[bjorn-spockeli]

Are you able to see if sd_softdevice_enable() returns an error code or doesnt it return at all? As long as you do not step after you hit a breakpoint set after ble_stack_init is called you should be OK.

[Shane Anderson]

Hello Fabi,

I believe I'm encountering the same error and I think I know why. Note: I'm using the S140 softdevice on the nRF52840, but I believe it's the same issue.

When you are debugging with the J-Link, you load your app past the SoftDevice and the debugger will typically start you in the Reset_Handler of your app. The key here is that debugging avoids running the Reset_Handler in the SoftDevice, which appears to setup a bunch of stuff that must be done before calling sd_softdevice_enable.

On the flip-side, a true reset, launches using the Reset_Handler as specified in the SoftDevice, which then eventually runs the Reset_Handler of your app. As it should be.

So, I think you can possibly specify the initial actions of your debugger and instruct it to do a hardware reset and run from there. I'm currently stuck on this part--I'm using Segger's Ozone and can't seem to find a way to specify the Reset Strategy. However, I have a pretty easy workaround--use the reset button in Ozone and then run from there--that seems to do the trick--I just wish I could get it to reset on first debug.

I hope that helps! (And I hope this is what's really going on..)

[bjorn-spockeli]

@fwanner: Does the approach described by Shane work for you?