Seems it's really EEPROM emulation using a page/sector of flash on this chip. So most EEPROM rewrite endurance tricks are actually using FLASH endurance tricks that reduce sector erase cycles.

https://github.com/jwrw/ESP_EEPROM
https://github.com/xoseperez/eeprom_rotate

 

One basic trick is to only update values in EEPROM. That is, check that the value to be written is indeed different than the value already stored. This can be done with a read in an if statement before writing. The Arduino EEPROM library has an intrinsic method defined to do this - EEPROM.update(). But it’s simple enough to code. Some pseudo-code...

if(EEPROM.read(address)<>new value) EEPROM.write(address,new value);​

 

Real EEPROM usually has per byte erase-and-write capabilities while FLASH does not. ESP32 EEPROM (emulation using FLASH) leveling write routines that assumes the per byte erase-and-write capabilities of EEPROM will quickly wear the entire FLASH storage sector unless the sector cells have been manufactured for extra endurance.

 

Check out F-RAM. https://www.cypress.com/products/f-ram-nonvolatile-ferroelectric-ram

https://www.cypress.com/file/126916/download

151 year retention.

 

hi @djsfantasi

There is an inbuilt Arduino Function for the sequence you suggest.
https://www.arduino.cc/en/Reference/EEPROMPut

https://www.arduino.cc/en/Reference/EEPROMUpdate
E

 

I am currently working on implementing rotate EEPROM as suggested in one of the posts above.
https://github.com/xoseperez/eeprom_rotate
If I uderstand correctly, when I create multiple partitions of EEPROM, it is automatically going to switch between partitions and not write to the same partition once it has been written.
For example, if I create 2 EEPROM partitions, my EEPROM lifecycle should extend by 2 times

 

hi zazas,
I currently using an Arduino UNO to create the required Reset etc ..
Let you know if I have any success.
E

 

hi @djsfantasi

There is an inbuilt Arduino Function for the sequence you suggest.
https://www.arduino.cc/en/Reference/EEPROMPut

https://www.arduino.cc/en/Reference/EEPROMUpdate
E

Yes, I know

The Arduino EEPROM library has an intrinsic method defined to do this - EEPROM.update().

 

Take step back
writting to EEPROM repeatably is going to wear it out

Solutions.

a) wear levelling, or something like a file system
easy way, set aside a bunch of eeprom, say 128 times what you need, start with all cells at value you wont see liek FF
and each time you write, read block till you find next free cell, and wirte that
And when all cells are written, erase the block and start at beginning,
or variations of this , such as two blocks ,

b) Use ram , and only write to EEPROM on power down, You need a good interrupt routine to do this

c) Don't use the eeprom, use say a RTC, that has battery back up and ram available.
if you don't have RTC on board, something like this might fit , or one of the many Chinese versions

https://uk.rs-online.com/web/p/cloc...Tnx1RpjK9RHqYX-SxpRoCgLcQAvD_BwE&gclsrc=aw.ds

 

...Perhaps I should think of a way to do a restart without actually powering off the devices, But I think at some point I will still need to do a power off restart...

In my ESP32 project when I loose the WiFi connection I found no way to restore it besides a reboot. So in code when I detect the dropout I run the "ESP.restart();" routine and reconnect that way.

At start up I check for a magic number in one variable. If I see that exact value I know the data in memory is current so I use it instead of a reset.

You could just add a RESET button to yours.

 

Are you writing to the eeprom 100x per day or restarting and reading 100x per day or both?

 

In the past I have used a circuit to detect that power is dropping out (have to do that before the regulator) and do your write only then...

 

Take step back
writting to EEPROM repeatably is going to wear it out

Solutions.

a) wear levelling, or something like a file system
easy way, set aside a bunch of eeprom, say 128 times what you need, start with all cells at value you wont see liek FF
and each time you write, read block till you find next free cell, and wirte that
And when all cells are written, erase the block and start at beginning,
or variations of this , such as two blocks ,

b) Use ram , and only write to EEPROM on power down, You need a good interrupt routine to do this

c) Don't use the eeprom, use say a RTC, that has battery back up and ram available.
if you don't have RTC on board, something like this might fit , or one of the many Chinese versions

https://uk.rs-online.com/web/p/clock-timer-development-tools/1840476/?cm_mmc=UK-PLA-DS3A-_-google-_-CSS_UK_EN_Raspberry_Pi_&_Arduino_&_Development_Tools_Whoop-_-Clock+&+Timer+Development+Tools_Whoop-_-1840476&matchtype=&pla-312891338600&gclid=CjwKCAiAgc-ABhA7EiwAjev-j0LiJRj_MF3RR2IE_NbGIPHZ8y3FOLaFK8JTnx1RpjK9RHqYX-SxpRoCgLcQAvD_BwE&gclsrc=aw.ds

Thanks for the reply

a) I dont think I can implement wear leveling on the ESP32 since its emulated on top of NAND flash. When I want to wryte a single byte to my flash, it must erasa a whole sector of flash memory.

b) I only write to EEPROM on power down , The power downs might be frequent that is the problem

c) Interesting Idea i need to read more about it

 

Are you writing to the eeprom 100x per day or restarting and reading 100x per day or both?

I guess both? I only write to eeprom when I restart the device. Upon restart, I am reading back whatever has been previously written before restart

 

hi zanzas,
If you recall you had a query on how to Reset/Initialise the EEPROM counter at first power On.
Check this millis method, tested it works OK with a UNO.

E

 

I guess both? I only write to eeprom when I restart the device. Upon restart, I am reading back whatever has been previously written before restart

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/storage/spi_flash.html

 

Assuming you have lots of EEPROM space, just create redundant copies of data. Simple example, just write each field 3 times. When reading, select two of the three values that agree. Three not enough? Try seven. You could deploy CRCs to check for data integrity. Lots of options.

 

Assuming you have lots of EEPROM space, just create redundant copies of data. Simple example, just write each field 3 times. When reading, select two of the three values that agree. Three not enough? Try seven. You could deploy CRCs to check for data integrity. Lots of options.

Which will cause the eeprom to fail three to seven times as fast.

The best suggestion I have seen is to have capacitor backup the microprocessor power and monitor the primary power so that it’s failure triggers an interrupt which saves data to the eeprom. Otherwise, don’t write to the eeprom. This results in the absolute minimum number of writes.

The second suggestion is to initialize the eeprom with a flag value, such as FF. Then, count the number of writes (storing that in two bytes of eeprom) and when the counter overflows (~65000, which is close to 100,000), increment the eeprom address to the next available locations. There’s several details (determining the next available locations for example) that needs to be worked out for this algorithm, but this is the basic idea.

 

All of these suggestions are known and considered in embedded designs. You have to pick your favorites according to what your device needs. It's not that complicated. I'd say it's just as important to detect a failure as mitigate the effects of one.

 

Which will cause the eeprom to fail three to seven times as fast.

The best suggestion I have seen is to have capacitor backup the microprocessor power and monitor the primary power so that it’s failure triggers an interrupt which saves data to the eeprom. Otherwise, don’t write to the eeprom. This results in the absolute minimum number of writes.

The second suggestion is to initialize the eeprom with a flag value, such as FF. Then, count the number of writes (storing that in two bytes of eeprom) and when the counter overflows (~65000, which is close to 100,000), increment the eeprom address to the next available locations. There’s several details (determining the next available locations for example) that needs to be worked out for this algorithm, but this is the basic idea.

Thanks all for the responses! I am trying to implement something simmilar what you mention for second suggestion.


From what I know about the flash memory although I could not confirm that about the 4MB embedded SPI flash memory in my ESP32 device as I could not find a lot of information about that yet:

Write operation usually writes a single "page" to a flash memory, so If I know what is a "page" size I can split my flash memory into pages lets say 10 pages and every restart I would increment a page so I do not write to the same page over and over again.
After I reach page 10, I would just return back to page 0 and continue.

The only problem with this, is I need to keep track which page I am at, and in order to do that, I need to save that variable into static memory location so I know where to access it at all times. In my understanding, this memory location is going to fail fastest since its going to be overwritten everytime