Fatal Error

[Jan Kinander]

Using the debugger in SEGGER Embedded Studio and two nRF52-SDK circuit boards, I am stepping through code from the nRF5_SDK_17.0.2 examples.

Very often I end up
in file app_error_weak.c,
in function __WEAK void app_error_fault_handler(uint32_t id, uint32_t pc, uint32_t info)
at macro NRF_BREAKPOINT_COND; // On assert, the system can only recover with a reset.

Why is that?

Jan Kinander

[Amanda Hsieh]

Hi, 

There are several discussions about "NRF_BREAKPOINT_COND" in Devzone. I suggest you read through them first to try if the suggestions can solve your problem.

Don't forget to erase the kit every time before programming. You need to set the DEBUG flag in your preprocessor symbols to enable the section, then you can set a breakpoint at the same place, but then you can find the file name, line number and error code in the log. 

Regards,
Amanda

[Jan Kinander]

Now I have read the five related discussions below, but I can't see that neither of them correspond to my problem. Which is: after a few single-steps I end up in the HardFault trap in function app_error_fault_handler(), passing "SOFTDEVICE: ASSERTION FAILED" down to NRF_BREAKPOINT_COND. The call stack tells me nothing, just two anonymous addresses.

Are there any real-time processes on the nRF52-DK that are intimidated by my single-stepping?

[Amanda Hsieh]

Hi Jan, 

If you search for SOFTDEVICE: ASSERTION FAILED you may get relevant search results you may try.

See Vidar's answer in this post. 

-Amanda

[Jan Kinander]

In the case with id 267217, Vidar wries: 

One of the challenges when debugging with the Softdevice, or any other protocol stack with hard timing requirements for that matter, is that it will fail to meet those timing requirements if the CPU gets halted for too long. This means you can't single step through the application code without raising this SD assert.