NRF_BREAKPOINT_COND in debug

RE: NRF_BREAKPOINT_COND in debug

Murray — Fri, 07 Aug 2020 03:35:15 GMT

I also find this issue in ble_app_buttonless_dfu project. The version is SDK17. How can I resolve it?

RE: NRF_BREAKPOINT_COND in debug

Odman — Wed, 13 May 2020 21:10:20 GMT

Hi. This is an old topic, but I see exactly this problem in nRF SDK 16.0.0. Has there been any resolution to this?

RE: NRF_BREAKPOINT_COND in debug

ocram — Fri, 28 Sep 2018 10:02:51 GMT

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.

RE: NRF_BREAKPOINT_COND in debug

Elkana — Thu, 06 Sep 2018 09:49:06 GMT

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

RE: NRF_BREAKPOINT_COND in debug

Alaa — Sun, 08 Apr 2018 12:09:41 GMT

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!

RE: NRF_BREAKPOINT_COND in debug

Rune Holmgren — Wed, 04 Apr 2018 09:11:29 GMT

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

RE: NRF_BREAKPOINT_COND in debug

rraa — Tue, 03 Apr 2018 13:16:42 GMT

Did you try debugging different programme?