Extending lifetime and reliability in EEPROMs

Dwayne Reid of Trinity Electronics Systems Ltd Edmonton, AB, CANADA says reguarding a data logging application:

When the system powers down, all I have is the data stored in eeprom. I am currently using 8 records of 32 bytes each in the buffer - another record is stored at some time varying from 1 minute to an hour.

Each record includes a CRC to warn me of a corrupted record or damaged eeprom. If a damaged sectoin of eeprom is found, I swap in one of 7 spare chunks (just change the pointer in my 'housekeeping' section.

Essentially, I consider any location that gets written often to be subject to damage. Thats why I don't keep my buffer pointer in eeprom - it would have to be written every time a new record was written - and, if that location died, I would have no way of dealing with it. The way I have it set up now, my housekeeping section get written once upon first power-up, then written only when necessary to map out a defective section of eeprom. Each of the 8 records currently in use contains the 1 byte sequence count - I simply need to find out which count is highest so that I can set my buffer pointer to that record.

I start off with 512 bytes of eeprom. This is divided into 16 chunks of 32 bytes each. One of those chunks is reserved for what I call 'housekeeping' - it contains 3 copies of the start addresses of the 8 records in my buffer. This leaves me with 7 spare chunks of eeprom that will get swapped in as required. When the last of those is gone, my buffer drops from 8 records down to 7, then 6, etc. Of course, when I have lost more than a couple of spare chunks, I'll signal that maintenance is required.

Wagner Lipnharski says that to allow eeprom to store data in a buffer reliably:

a) If you have an extra byte at the eeprom, just save the last IDentification block number there, or circular buffer pointer, so when you power up again, just read it and set the buffer pointer back, or search for the ID into the circular buffer.

b) If you DO NOT have this extra byte, or don't want to keep reducing the eeprom life, just reserve the "00" identification byte for the next empty block, use block ID's from 01 to FF. Whenever you write a block, write an extra byte of "00" after that block, *that* will be your mark of END OF CIRCULAR BUFFER. For sure this "00" will be recorder over the oldest block identification byte, but even so you would be able to read that block of data.

With this option, at power up, you just need to go to the beginning of the circular buffer, and start reading just the block ID's, looking for "00", so the most recent is exactly the previous one, the oldest the one with the "00".

Any other math solution doesn't work, since if your block ID's are also circular from 00 to FF, there is NO WAY to find out which one was the last, except in one condition:
If your circular buffer size is not a perfect multiple of the (block data size + Id) * 256. In this case you can search for a disrupt in ID sequence. For example, if you circular buffer is only 256 bytes long and your block size is 32 bytes:

ID  DATA (31Bytes)- - - - - - - ->
01  00 01 02 03 04 ... 1E --- begin of circular buffer
FD  00 01 02 03 04 ... 1E
FB  00 01 02 03 04 ... 1E
FC  00 01 02 03 04 ... 1E
FD  00 01 02 03 04 ... 1E
FE  00 01 02 03 04 ... 1E
FF  00 01 02 03 04 ... 1E.
00  00 01 02 03 04 ... 1E --- end of circular buffer

If the block size is fixed, then you see that the difference between two block ID's is different than 1 [ed: subtract and ignore carrys] it means the lower address block is the last one, if the circular buffer runs up address. In this example it is clear that the [record ID # 01] is the first on the buffer.

Again, this technique will not works if your circular buffer holds only 2 blocks, or its size is exactly the block size times 256 (to a 8 bits ID), so the disruption above 65 -- 62 would then be 65 -- 66.

Now, if you really don't need to store the block ID number, then: If the first data byte values follows some kind of rule, for example, it is always less than 7F, you could use the bit 7 turned on only for the next buffer available byte, so easy to scan when powering back on. Or if the data bytes never use some bit combination, use that combination at the next buffer available byte.

In any way, you need to remember that you have a limited quantity of write operations in the eeprom chip. There are eeproms for 100k or 1M recordings (never clear from manufacturer, temperature changes it)...

Ruben Jvnsson [ruben at pp.sbbs.se] of AB Liros Elektronik says:

I'm currently working on a project which includes a 24LC16B I2C EEPROM and a serial RS485 connection. The communication on the serial connection includes commands to directly write and read the contents in the EEPROM. When developing the software, I did a testprogram which constantly, by commands on the serial connection from a PC, writes a random value to the EEPROM and verifies that it can be read back. There is a counter which keeps track of how many times this has been done. The PC also writes a log-file where I can see any errors that has been detected (serial comm errors, eeprom verification error). I have run this routine at nights and weekends to see when the EEPROM failed. At first I thought there was something wrong with the software because the EEPROM never failed. But at last, this weekend, after about 12000000 (twelve million) write cycles to the EEPROM i started to get verification errors. This took a couple of weeks since the serial connection is only 2400 bps.

  .