nRF51822: Getting instruction address from the fault handlers

RE: nRF51822: Getting instruction address from the fault handlers

bojan — Tue, 17 Jan 2023 16:51:19 GMT

I've applied the approach you suggested. From my custom implementation of the HardFault_process() function, I was able to extract the PC value.

I after that used the addr2line tool of the arm compiler to find out more about which function/module is located on that PC address:

arm-none-eabi-addr2line.exe -e <your_path>/nrf51822_xxac.out -a PC

However, given the fact that we don't use SES IDE but compile through the Makefile, I needed to revert the workaround in hardfault_handler_gcc.c file described in this thread:

Is this reverting OK?

Anyway, thank you very much for your great support, Turbo J , Sigurd !

Cheers,
Bojan.

RE: nRF51822: Getting instruction address from the fault handlers

Sigurd — Tue, 17 Jan 2023 15:32:59 GMT

Hi,

I recommend having a look at the HardFault handling library in the SDK.

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v12.3.0/lib_hardfault.html

Add these to your projects:

$(SDK_ROOT)/components/libraries/hardfault/hardfault_implementation.c
$(SDK_ROOT)/components/libraries/hardfault/nrf51/handler/hardfault_handler_gcc.c (or *_keil/iar, depending on your toolchain)

And set HARDFAULT_HANDLER_ENABLED to 1 in sdk_config.h (and DEBUG_NRF in your preprocessor definitions to get even more info in the handler)

It will show you the PC value that triggered the fault(if the HW was able determine the location of the fault).

RE: nRF51822: Getting instruction address from the fault handlers

bojan — Tue, 17 Jan 2023 14:21:46 GMT

Thanks, Sigurd .

What about the instruction address (ia) that caused the HardFault? Can we get that from the HardFault_Handler() under some circumstances?

Best regards,
Bojan.

RE: nRF51822: Getting instruction address from the fault handlers

Sigurd — Tue, 17 Jan 2023 13:21:20 GMT

[quote user="bojan"]Where can I find something more about the meaning of fault identifier (id) and info fields?[/quote]

Take a look at how the app_error_save_and_stop() parses the id and info field

Snippet:

void app_error_save_and_stop(uint32_t id, uint32_t pc, uint32_t info)
{
    /* static error variables - in order to prevent removal by optimizers */
    static volatile struct
    {
        uint32_t        fault_id;
        uint32_t        pc;
        uint32_t        error_info;
        assert_info_t * p_assert_info;
        error_info_t  * p_error_info;
        ret_code_t      err_code;
        uint32_t        line_num;
        const uint8_t * p_file_name;
    } m_error_data = {0};

    // The following variable helps Keil keep the call stack visible, in addition, it can be set to
    // 0 in the debugger to continue executing code after the error check.
    volatile bool loop = true;
    UNUSED_VARIABLE(loop);

    m_error_data.fault_id   = id;
    m_error_data.pc         = pc;
    m_error_data.error_info = info;

    switch (id)
    {
        case NRF_FAULT_ID_SDK_ASSERT:
            m_error_data.p_assert_info = (assert_info_t *)info;
            m_error_data.line_num      = m_error_data.p_assert_info->line_num;
            m_error_data.p_file_name   = m_error_data.p_assert_info->p_file_name;
            break;

        case NRF_FAULT_ID_SDK_ERROR:
            m_error_data.p_error_info = (error_info_t *)info;
            m_error_data.err_code     = m_error_data.p_error_info->err_code;
            m_error_data.line_num     = m_error_data.p_error_info->line_num;
            m_error_data.p_file_name  = m_error_data.p_error_info->p_file_name;
            break;
    }

    UNUSED_VARIABLE(m_error_data);

    // If printing is disrupted, remove the irq calls, or set the loop variable to 0 in the debugger.
    __disable_irq();
    while (loop);

    __enable_irq();
}

RE: nRF51822: Getting instruction address from the fault handlers

bojan — Mon, 16 Jan 2023 20:56:14 GMT

Thanks!

Where can I find something more about the meaning of fault identifier (id) and info fields?

RE: nRF51822: Getting instruction address from the fault handlers

Turbo J — Mon, 16 Jan 2023 20:35:16 GMT

The app_error_fault_handler() is a normal function, but the calling (on the SDK side) contains tons of compiler magic and IFDEFs. It is possible to deactivate the info functionality in order to save flash memory.

Not sure if the "pc" argument actually ever worked, I always used the stuff in "info" for app errors.

RE: nRF51822: Getting instruction address from the fault handlers

bojan — Mon, 16 Jan 2023 20:23:50 GMT

Thanks for the fast feedback, Turbo J

We have declared both functions as "naked" with:

void HardFault_Handler(void) __attribute__(( naked ));
void app_error_fault_handler(uint32_t id, uint32_t pc, uint32_t info) __attribute__(( naked ));

So, for the devices in the wild, the best will be just to count the number of fault events (HardFault, App Error Fault)?

It will be much more useful for us if we could get some more details about the Faulty event so that we can fix the bug causing it.

RE: nRF51822: Getting instruction address from the fault handlers

Turbo J — Mon, 16 Jan 2023 20:10:05 GMT

You forgot to declare the Hardfault_Handler() to be "naked" (yes, that is an attribute in gcc). Otherwise it generates the normal pre stacking of any function type - like pushing LR for example.

Note that the softdevice already handles hard faults and will mess up the stack - at least it tries to read from it (which can cause a lockup reset).

Its better to use the vector catch in the debugger. For devices in the wild its better to just NVIC_SystemReset() in the Fault handler - you have to be lucky to get a function call working properly.