RE: How to decode info in app_error_save_and_stop

Vidar Berg — Tue, 02 Jun 2020 06:36:42 GMT

Hello,

I can tell from the values that you are reading from the vector table at address 0. In other words, you don't have a valid info pointer. I suggest you create a new ticket with more details about the problem. And remember to mention what SDK and SD version you use.

RE: How to decode info in app_error_save_and_stop

Somesh Burkule — Fri, 29 May 2020 15:50:01 GMT

Hello,

I have debugged my code and getting NRF_FAULT_ID_SDK_ERROR with following info:

err_code: 0x0000057D

line_num: 0x20000400

p_file_name: 0x000008E9

How to decode this?

RE: How to decode info in app_error_save_and_stop

Vidar Berg — Mon, 19 Mar 2018 09:11:55 GMT

m_error_data.fault_id corresponds to the id parameter passed to app_error_save_and_stop(uint32_t id, uint32_t pc, uint32_t info), and is used to determine the error source - i.e., if it is a SDK or Softdevice error.

Only SDK errors include pointers to assert_info_t and error_info_t. For softdevice asserts , the info pointer will in most case be zero:

#define NRF_FAULT_ID_APP_MEMACC (NRF_FAULT_ID_APP_RANGE_START + 1)

Application invalid memory access (nRF52 only). The info parameter will contain 0x00000000, in case of SoftDevice RAM access violation. In case of SoftDevice peripheral register violation the info parameter will contain the sub-region number of PREGION[0], on whose address range the disallowed write access caused the memory access fault.

#define NRF_FAULT_ID_SD_ASSERT (NRF_FAULT_ID_SD_RANGE_START + 1)

SoftDevice assertion. The info parameter is reserved for future used.

This means that if you use the info pointer, and there was a softdevice assert, you are most likely going to be reading out the vector table at address 0x0 in flash.

MBR vector table from s132 v3.0.0 which corresponds with the error information you got:

Note: I used the default app_error_save_and_stop() implementation from SDK 12.3.0 as reference:

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: How to decode info in app_error_save_and_stop

dcollier8 — Fri, 16 Mar 2018 18:00:26 GMT

Error code was 1401 (0x579), sorry I left that out. None of the links in your reply match these codes. Is there any way to decode them or look them up ? Line number = 0x400, filename= 0x8e5

RE: How to decode info in app_error_save_and_stop

Vidar Berg — Fri, 16 Mar 2018 17:52:50 GMT

Hi,

The info pointer will typically be set to 'NULL' in case of a softdevice assert, and only include fault id and a pc value (PC shows where the assert occurred internally in the softdevice). You can determine if it was a softdevice assert by checking the .fault_id against the fault id types here and here.