How can I keep information in a log when an error occurs?

[sdi_kei]

I am developing with nrf52832 (s132 v7.0.1, SDK v17.0.0) as a peripheral device.

When an error occurs, we would like to store information in Flash about what caused the error and reset the system.

Since it is difficult to put the information in Flash when a reset occurs, we believe we need to store the information in RAM and then read the information after a reboot.
However, I do not know if there is a handler that is called when an error occurs, and I do not know what information can be retrieved.

Is there any handler called when an error occurs? Also, in the handler that is called, does it know what to reset by?
If you have documentation, I would like to know.

Thank you in advance.

[Jared]

Hi,

This is already a feature of the logger module when you use the Flash as a backend. See the CLI example on how to use the backend.

regards

Jared  

[sdi_kei]

Hello.

I ran the cli sample and ran "error", but no data of any kind was stored in Flash.
How do I enter the command to confirm that I have written to Flash?

Also, I am thinking that I would use NRF_LOG_FINAL_FLUSH because what I want to implement is to get a log of the crash.
I was unable to find where in the sample it does this, so could you please let me know?

Thank you in advance.

[Jared]

Hi there,

Sorry for the misunderstanding.

The flash backend consists of two parts:

1. Flashlog: Which is used to store log entries during the application lifetime.
2. Crashlog: which is used to store log entries only before an error condition with the usage of NRF_LOG_FINAL_FLUSH.

The CLI example only use the flashlog, which means that it only stores log entries during the application lifetime.

If you want to use crashlog then you have to call NRF_LOG_FINAL_FLUSH in the error handler as in the dfu secure bootloader example:

You should be able to read out the log after a reset by using nrf_log_backend_flash_next_entry_get().

regards

Jared 

[sdi_kei]

Hello.

I implemented Error handling with reference to cli, but it was not saved as a log.
Here is the process I referred to.

static void on_error(void)
{
    NRF_LOG_FINAL_FLUSH();

#if NRF_MODULE_ENABLED(NRF_LOG_BACKEND_RTT)
    // To allow the buffer to be flushed by the host.
    nrf_delay_ms(100);
#endif
#ifdef NRF_DFU_DEBUG_VERSION
    NRF_BREAKPOINT_COND;
#endif
    NVIC_SystemReset();
}


void app_error_handler(uint32_t error_code, uint32_t line_num, const uint8_t * p_file_name)
{
    NRF_LOG_ERROR("%s:%d", p_file_name, line_num);
    on_error();
}


void app_error_fault_handler(uint32_t id, uint32_t pc, uint32_t info)
{
    NRF_LOG_ERROR("Received a fault! id: 0x%08x, pc: 0x%08x, info: 0x%08x", id, pc, info);
    on_error();
}


void app_error_handler_bare(uint32_t error_code)
{
    NRF_LOG_ERROR("Received an error: 0x%08x!", error_code);
    on_error();
}

int main(void)
{
    ret_code_t err_code;
    uint32_t token = 0;
    nrf_log_header_t * p_header;
    uint8_t * p_data = NULL;
    
    /* Initialization process is omitted. */
    
    err_code = nrf_log_backend_flash_next_entry_get(&token, &p_header, &p_data);
    if (err_code != NRF_SUCCESS) {
        NRF_LOG_INFO("No Logs.");
    }
    
    err_code = sd_power_dcdc_mode_set(NRF_POWER_DCDC_ENABLE);
    err_code = NRF_ERROR_INVALID_PARAM;
    APP_ERROR_CHECK(err_code);
}

Why does "No Logs." occur?
Is it correct that the log is saved in which FDS?

Thank you in advance.

[Jared]

Hi,

Can you try to follow this thread and see if you're able to implement and read the logs by reading the memory with the debugger as shown in the thread?

regards

Jared 

[sdi_kei]

Hello.

Thank you for sharing your thread with us.
I will check it out for reference.

I am not aware of what information can be saved in the error log.
Does it also save information when it is reset by WDT?

Thank you in advance.

[Jared]

Hi,

I doubt you'll have time to flush the logs before the system resets, you can enable an application interrupt to be generated once a TIMEOUT event has been generated (see the wdt example), but this will only postpone the reset with two 32.768 kHz clock cycles. 

regards

Jared