nrf52840 SDK16 - app_error_save_and_stop never been called

Hi,

This macro have been intentionally located before the app_error_save_and_stop right? What is the reason?

Yes. The reason for having NRF_BREAKPOINT_COND there is that if you are debugging the debugger will break there immediately, which is typically what you want in that case. If there is no active debug session, this does nothing, and it continues. With app_error_save_and_stop the state of the system is maintained as it disables interrupt and enters a eternal loop. But you will not see this before pausing, as there is no automatic breakpoint here. But this is very useful if for instance you have a device that failed somehow, and then you decide to attach the debugger.

Should I comment out this breakpoint macro? Is it safe?

I do not see why you would want to comment it out, but if you really prefer to not have an automatic breakpoint here, then it is entirely safe to remove NRF_BREAKPOINT_COND.

Thank you Einar!!

The DHCSR sets when a debug session starts or when the debugger is connected with the target?

#if __CORTEX_M == 0x04
#define NRF_BREAKPOINT_COND do {                            \
    /* C_DEBUGEN == 1 -> Debugger Connected */              \
    if (CoreDebug->DHCSR & CoreDebug_DHCSR_C_DEBUGEN_Msk)   \
    {                                                       \
       /* Generate breakpoint if debugger is connected */   \
            NRF_BREAKPOINT;                                 \
    } \
    }while (0)

user7377 said:

But this is very useful if for instance you have a device that failed somehow, and then you decide to attach the debugger.

Could you provide some more information about that?

Nikosant03 said:

The DHCSR sets when a debug session starts or when the debugger is connected with the target?

It is not enough to connect the debugger physically, a debug session must be started.

Nikosant03 said:

Could you provide some more information about that?

There is not that much to say. If you have a device which is running a debug guild of the firmware and  error is detected you want to preserve the state so that you can investigate from a debugger. And that is why the default error handler behaves this way. It is a very common approach and other SDKs for other MCUs typically also have a similar mechanism. Note that for a release build where DEBUG is not defined, app_error_save_and_stop() is never called and the device is reset instead, which is what you normally want to do in the field if an unexpected error happens.