NRF_BREAKPOINT_COND in debug

[Alaa]

Hi,

I started coding form ble_app_uart, and whenever I set a breakpoint and it's caught, then I press Resume (eclipse), the code falls on NRF_BREAKPOINT_COND in app_error_fault_handler().

The callstack is empty so I don't know where this is coming from...

But it happens only after stopping on some breakpoint and then resuming.

I'm using SDK 14.

Thanks

[rraa]

Did you try debugging different programme?

[Rune Holmgren]

Resuming after breakpoints is not a problem if you are simply doing regular microcontroller activities. However, if you are running the SoftDevice Bluetooth stack there are many operations the SoftDevice will have to schedule and perform at specific timings to conform to the BLE specification. Setting breakpoints while the SoftDevice is running will very often cause the SoftDevice to get into some unintended state. When you attempt to resume afterward the app_error_fault_handler will be called after the first error from the SoftDevice is returned.

When debugging this can be annoying, but it's implemented that way to ensure that production devices will reset to a working state if they ever encounter some rare error which would otherwise brick the device or force the user to manually power cycle it.

If you really need to be able to debug a running device without getting into the error handler you can use monitoring mode debugging. In this mode, the debugger is just spying on the device as it is running without actually stopping the CPU, so the device is still running the BLE stack. Note that it's a bit more complex to set up and requires some changes to the project on the device.

Best regards,
Rune Holmgren

[Alaa]

Thanks for the detailed explanation and the link. The steps in the link look very clear. I might give it a try later and if I do I will update here. Thanks!

[Elkana]

Hi, I understand the reason for this, but is it possible:

1. To limit this behavior only when BLE is active (as opposed to SD enabled)?

2. To disable when compiled with "DEBUG" flag?

Although there are others, "step by step" is still one of the most important and effective debug methods, and it is a shame to miss it.

Thanks

[ocram]

for me it worked to overwrite the app_error_fault_handler that calls the NRF_BREAKPOINT_COND. The softdevice functionality might not recover after stopping, but I can run the normal system with full functionality until my first breakpoint and then still step or set other working breakpoints in my code.

To not miss other unexpected asserts I found it also very useful to redirect any Assert information to the Segger RTT and output them by the RTT-Client.