EEPROM rotation for ESP8266 and ESP32


Xose PĂ©rez over at Tinkerman writes:

The Arduino Core for ESP8266 and ESP32 uses one SPI flash memory sector to emulate an EEPROM. When you initialize the EEPROM object (calling begin) it reads the contents of the sector into a memory buffer. Reading a writing is done over that in-memory buffer. Whenever you call commit it write the contents back to the flash sector.
Due to the nature of this flash memory (NOR) a full sector erase must be done prior to write any new data. If a power failure (intended or not) happens during this process the sector data is lost.
Also, writing data to a NOR memory can be done byte by byte but only to change a 1 to a 0. The only way to turn 0s to 1s is to perform a sector erase which turns all memory positions in that sector to 1. But sector erasing must be done in full sectors, thus wearing out the flash memory faster.

How can we overcome these problems?

Full details at

Join the Conversation


  1. Please note that he appeared to have licensed his code under LGPL; I guess he thinks he’s hot stuff. This kind of thing, which is pretty common, is more critical for MCUs with NAND-only flash, where you wish to have some non-volatile storage of high endurance but do not wish to add a NOR part. That parts in the pix looks like 25-something. About all of the 25AA and 25LC Microchip datasheets that I have with me says their endurance is over 1 million cycles. Perhaps he should learn to read datasheets first…

    There are plenty of material that is not LGPL, for example, see Microchip’s AN1095. Personally I prefer not to encumber my code with LGPL just for a small thing like this and would definitely prefer to keep to my own implementation. Anything else needing higher amounts of storage and has tens of milliamps to spare can use SD or micro SD cards.

    1. May I ask why do you think its such a bad idea to release the library under LGPL? I understand you are the kind of person (probably an EE) that only trusts his own stuff, but also one of those (again, probably EE) that can’t help criticising anything that’s not up to his standards.
      There is a reason to create that library for that specific chip and framework. It is explained in the post which maybe you have yet to read.

      1. I can only guess, but I assume the LGPL remark refers to it being mostly used for things the author thinks important and unique enough to be a) likely to be reused widely and b) worth protecting against “proprietarisation”. Everything else hardly warrants more than a “do whatever you want with it if you even find it useful” MIT, BSD or similar license. As for the critical part., it tends to come around as a reaction to the incredible amount of gratuitous hype, pompousness and laxity found in the world of tech these days, which people accustomed to rigor, reliability and seriously challenging problems tend to find deeply disturbing, resulting in cynical comments directed at anything less. Then again, I can only speak for myself…

    2. Being lazy because “oh the datasheet says I’ve got a million cycles, I can just hammer it and not give a shit” isn’t the path to production quality code. I wouldn’t hire an engineer if they said that to me.

      How often will your application update the flash? How long is it expected to run unattended for? Unless your answers are “eh, it only needs to run for an hour and nobody else but me is going to use this code” then do the math. It’s completely naive to assume a big number in a datasheet means you can ignore it.

Leave a comment

Leave a Reply to pelrun Cancel reply

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail. You can also subscribe without commenting.