This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Hardfault Handler implementation library - not getting NRF_LOG_ERROR info

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!

Parents
  • Just to close the bug report....I was able to finally fix the problem. The hardfault was an unauthorized memory access due to the fact that I put a wrong valueas PACKET_PAYLOAD_MAXSIZE on the radio configuration. This was causing problems to the DMA and was messing things up.

    Now that I put the correct value the hardfault is not happening again.

Reply
  • Just to close the bug report....I was able to finally fix the problem. The hardfault was an unauthorized memory access due to the fact that I put a wrong valueas PACKET_PAYLOAD_MAXSIZE on the radio configuration. This was causing problems to the DMA and was messing things up.

    Now that I put the correct value the hardfault is not happening again.

Children
No Data
Related