Page 1 of 1

Better use of NO INIT section

Posted: Sat Aug 25, 2018 7:30 pm
by urbanze
I'm trying to improve using the "NO_INIT" section to keep data on any type of reset (including some POWER_ON with BOD), but I need more information ...

For now, the simplest method would be to initialize the variable if the reason for the reset is POWER_ON, but some tests with BOD to save variables, even the reason is POWER_ON, the variables are still saved. This added me a second check that if the variable has a value outside my scope (eg. 0-128), I know it has been "reset".

But there the problem is born, what are the chances of the variable NO_INIT being initialized with a value within my scope? In all tests, the variables init with very large random(?) values ​​(> 1G) ...

1. What values ​​and why do they receive these values?

2. What is their scope when the RAM is initialized (totally random)?

3. Is there any bit or something specifying that the values ​​have been changed? How can I improve the method of initializing variables if even with POWER_ON they can keep what was saved.

A simple example of what I have been using to know if my values ​​have been overwritten:

Code: Select all

RTC_NOINIT_ATTR uint8_t x;

if (rtc_get_reset_reason(0) == POWERON_RESET && x > 5000)
{
	x = 0;
}

Re: Better use of NO INIT section

Posted: Sat Aug 25, 2018 7:46 pm
by ESP_igrr
After power on, memory contents is random. The exact pattern for "randomness" will differ from one chip to another.
You may be able to detect whether your variables are "valid" by calculating a hash sum (or a CRC) and saving that in NOINIT section along with the variables. If after reset you find that CRC(variables) == saved CRC, then there's a good chance that variables have been preserved over the course of reset.

Re: Better use of NO INIT section

Posted: Sat Aug 25, 2018 8:20 pm
by urbanze
ESP_igrr wrote:After power on, memory contents is random. The exact pattern for "randomness" will differ from one chip to another.
You may be able to detect whether your variables are "valid" by calculating a hash sum (or a CRC) and saving that in NOINIT section along with the variables. If after reset you find that CRC(variables) == saved CRC, then there's a good chance that variables have been preserved over the course of reset.
Some tests with data saving via BOD, kept the data saved even the reason for the reset being "POWER_ON", so I can not just use this parameter to initialize variables. I will think better about algorithms for data integrity and in the future put some results here. Thank you

Re: Better use of NO INIT section

Posted: Sat Aug 25, 2018 8:38 pm
by urbanze
I think it simpler to calculate the CRC/etc of address than I am NOT using. Since my var addresses change frequently, it is easier to calculate CRC from other addresses that MUST(?) remain fixed until the next reset.

What is the address scope of RTC_NOINIT? (0xYYYY to 0xZZZZ)?