This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

NRF_BREAKPOINT_COND causing hang before NVIC_SystemReset() can be executed

I can't quite seem to figure this one out.

We've got the APP_ERROR_CHECK macro on our functions that return NRF errors. When there is a genuine error, the system does not reset but rather it hangs. I've followed the code through to `app_error_weak.c` where it seems there is a NRF_BREAKPOINT_COND right before a NVIC_SystemReset() call. See line 100.

The code seems to hang on NRF_BREAKPOINT_COND and not proceed to the next line.

In production, it's obviously important for the system to reset when it hits an error.

I am not using a DEBUG flag in the preprocessor (it's the Release config), so it should definitely continue onto the next line. When I comment out the NRF_BREAKPOINT_COND line, it works as expected and system does a soft reset.

I've tried this with and without a J-Link connected and the behaviour is the same.

The documentation simply says:

#define NRF_BREAKPOINT_COND   NRF_BREAKPOINT
Macro for setting a breakpoint.

If it is possible to detect debugger presence then it is set only in that case.

SDK version: 17.0.2
  • Hello,

    I have not noticed that the breakpoint was conditional on the CoreDebug_DHCSR_C_DEBUGEN bit before. The problem is that this bit cannot be used to reliably detect if the device is in Debug Interface mode or not. It is set when you program the device through the debug interface, but is not necessarily cleared again when the programmer exits debug interface mode afterwards. You have to do a power on reset or pinreset to clear it.

    NRF_BREAKPOINT_COND macro:

    #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)

    I will report this as a bug internally. I don't think NRF_BREAKPOINT_COND should be called at all in release builds.

    Best regards,

    Vidar

  • Thanks for your prompt response. Would it be safe to assume that as a temporary fix for release we could just move that line so that it's only run when the DEBUG flag is present?

  • Yes, I believe this is the correct fix. I do not think it should be necessary to include the breakpoint when the DEBUG flag is not present.

Related