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.

[sdi_kei]

Hello.

Thank you for the explanation of WDT.
What information can be saved for other errors?

Thank you in advance.

[Jared]

Hi,

You should be able to store simple error logs for other errors. 

regards
Jared 

[sdi_kei]

Hello.

The problem with "No Logs." was due to the fact that the flashlog was not initialized before nrf_log_backend_flash_next_entry_get.
After initialization and re-execution after generating the error, the "No Logs." does not occur anymore.

However, when we checked the argument of nrf_log_backend_flash_next_entry_get, the data was 0xFF and it seemed that the error information was not obtained.

I don't know what is the cause of not being able to get the error information.
If so, what kind of data is contained?

Thank you in advance.

[ovrebekk]

Hi 

Jared is out of office this week, and I will handle your case in the mean time. 

What kind of error occurred in this case? 

Are you sure that there was enough time provided for the data to be written to flash?

A workaround to the issue of not being able to write to the flash in time is to write the logging data to RAM instead, and run some code on reset that checks this RAM region and copies it into flash after the device is reset. Then you should be able to write to the log even in the case of a WDT reset. 

Best regards
Torbjørn

[sdi_kei]

Hello.

The return value of nrf_log_backend_flash_next_entry_get is NRF_SUCCESS, so it is not an error. But there is only 0xFF in p_data.

As for the wait time, a delay of 100 ms is added after NRF_LOG_FINAL_FLUSH.

ovrebekk said:

A workaround to the issue of not being able to write to the flash in time is to write the logging data to RAM instead, and run some code on reset that checks this RAM region and copies it into flash after the device is reset. Then you should be able to write to the log even in the case of a WDT reset. 

I would like to implement this, but could you please tell me how to do it?

Thank you in advance.

[Hung Bui]

Hi Kei, 

I'm taking over the case from Torbjørn. 

My understanding on what Torbjørn wrote here 

ovrebekk said:

Are you sure that there was enough time provided for the data to be written to flash?

Is that it's not the delay needed in the code for the LOG flush to finish, but the time the chip has before the WDT reset. Writing to flash would take time and in many cases it won't be able to finish the writing before the WDT reset triggered. This doesn't matter if you put a delay in the code or not. The WDT reset can preempt that and reset the chip. 

This is only applied for WDT reset, not on normal assert on error. I'm not so sure in your case you are looking for a solution to write to flash in normal assert or when WDT reset? 

I currently don't have an example that Torbjørn described. But what you can do is to try writing to a RAM read defined as non-init so that it won't be initialize to 0 when the chip booting up. For example:

static char error_info[ERROR_INFO_MAX_LEN] __attribute__((section(".non_init")));

Then in the WDT_IRQHandler you can add the information you need into error_info before the chip reset. 
After that when booting up, you can check error_info[] to see if there is any information in it. 

[sdi_kei]

Hello.

Thanks for the example.

I have deed that a WDT reset or soft reset has occurred that "RESETREAS" could be used.
We will also look into storing the soft reset in RAM, since we do not know what caused the reset.

Thank you very much.