Hardfault Handler implementation library - not getting NRF_LOG_ERROR info

[lbe]

Good morning everyone,

I am implementing a custom radio protocol on NRF52 without using the SoftDevice at the moment. For some reason, I get a HardFault which I am trying to understand.

I am working on an NRF52832 dev board with the JLink attached, I am using the Segger Embedded Studio and I have configured the sdk_config to show the output of the NRF_LOG_ERROR.

To be sure that this works fine, at the beginning of my main, I put an NRF_LOG_ERROR ("Application start") and this is displayed as expected while in debug mode.

I included the files hardfault_handler_gcc.c and hardfault_implementation.c, and when the HardFault occurs, I see that the debugger correctly stop at the first instruction of the HardFault_Handler function as shown below

void HardFault_Handler(void)
{
    __ASM volatile(
    "   tst lr, #4                              \n"

    /* PSP is quite simple and does not require additional handler */
    "   itt ne                                  \n"
    "   mrsne r0, psp                           \n"
    /* Jump to the handler, do not store LR - returning from handler just exits exception */
    "   bne  HardFault_Handler_Continue         \n"

    /* Processing MSP requires stack checking */
    "   mrs r0, msp                             \n"

    "   ldr   r1, =__StackTop                   \n"
    "   ldr   r2, =__StackLimit                 \n"

    /* MSP is in the range of the stack area */
    "   cmp   r0, r1                            \n"
    "   bhi   HardFault_MoveSP                  \n"
    "   cmp   r0, r2                            \n"
    "   bhi   HardFault_Handler_Continue        \n"

    "HardFault_MoveSP:                          \n"
    "   mov   sp, r1                            \n"
    "   mov   r0, #0                            \n"
    #if HARDFAULT_HANDLER_GDB_PSP_BACKTRACE
    "   mov r3, sp                              \n" /* Remember old SP */
    "   mov sp, r0                              \n" /* SP changed the pointer when hardfault was generated - we cannot just switch to PSP in exception */
    "   push {r3,lr}                            \n" /* Save old SP and LR on the task stack */
#if !defined(__SES_ARM)
    "   .cfi_def_cfa_offset 8                   \n"
    "   .cfi_offset 14, -4                      \n"
#endif
   /* No information about saved SP above (no .cfi_offset 13, -8).
    * In other case this would direct us back to using always MSP while backtracking */
    "   ldr r3, =%0                             \n"
    "   blx r3                                  \n"
    "   pop {r3,lr}                             \n"
    "   mov sp, r3                              \n"
    "   bx lr                                   \n"
#else // HARDFAULT_HANDLER_GDB_PSP_BACKTRACE
    "   ldr r3, =%0                             \n"
    "   bx r3                                   \n"
#endif
    "   .ltorg                                  \n"
    : : "X"(HardFault_c_handler)
    );
}

    "HardFault_Handler_Continue:                \n"

Then, if I push the "Continue" button in the debug mode of SES, the execution continues until the NRF_BREAKPOINT_COND instruction of hardfault_implementation.c , but the problem is that no NRF_LOG_ERROR is output on the Debug Terminal. So, of course, this limits drastically the utilility of this function....

If I try to go step by step in the debug mode, sometimes the system stops in the nrf_fprintf_format.c class, at a strlen instruction (line 109)....some other times it stops in a function 

__STATIC_INLINE void nrf_log_backend_panic_set(nrf_log_backend_t const * p_backend)  defined in nrf_log_backend_interface....

Do you have any clue what I am missing, or if this is a normal behaviour caused by the weird hardfault?

Thanks in advance for your help!

[haakonsh]

Put a breakpoint on line 109 of hardfault_implementation.c (SDK15.2) and step through the code to find the hardfault cause. You might want to disable the log module if you get stuck because of Its problems, they might be another symptom of your issue or a completely separate issue that we can handle after we've solved the hardfault issue.

[lbe]

Hello, 

thanks for your reply. Actually, I already tried what you suggested, but line 109 is not accepted as a valid breakpoint (the question mark you see on the left side of the code in Segger Embedded Studio). So, I put a breakpoint on a couple of line before [ uint32_t cfsr = SCB->CFSR;]. 

The problem is that the debugger correctly halts there, but then if I go through step by step, the debugger goes directly to line 148 [NRF_BREAKPOINT_COND;]. 

And if I try to read the p_stack information, it is always empty (0x000000).

I figured a way to temporarily avoid the Hardfault by changing a parameter in my protocol, but it is not a final solution, so I definitely need to understand what kind of hardfault I am getting so that I can find a solution.

Any other clue on how to obtain this information?

Thank you  

[haakonsh]

Aah. That whole section will get optimized out by the compiler. You need to enable the log module and set the compiler optimization level to 0. Are you using RTT or UART as the backend for the log module?

[lbe]

Well, this is getting weirder and weirder....I'll describe you what happens. So, I enabled the log module (I am using RTT, with a dev board connected to the computer and the SES in debug mode) and I changed the compiler optimization level. Here I obtain the first weird behavior: if the optimization level in SES is set to "Debug" (I don't see the "level 0" among the options) I don't have an Hardfault. I tried restarting several times and I never end in the hardfault routine. If I change the optimization level to "None", 

sometimes I fall in the hardfault routine, BUT

- when the code stops at the beginning of the assembler code (in hardfault_handler_gcc.c), if I press the "continue" button of the debugger (green arrow), then my code resumes execution: I never get to the breakpoint I set in the hardfault_implementation.gcc file

- If I go step by step by pressing F10, sometimes I get to the hardfault_implementaion breakpoint, where the p->stack is 0 and apparently the cfsr_msg is number [18] = "The processor has attempted an illegal load of EXC_RETURN to the PC, as a result of an invalid context, or an invalid EXC_RETURN value"

Sometimes, though, even if I go step by step, I end in nrf_log_backend_panic_set (in nrf_log_backend_interface), which seems to be related to a problem with the logger module?

I am completely lost,so I wait for clues on how to proceed. Thanks a lot.