Avoiding corruption in EEPROM Memory

David VanHorn says:

I'm going to center this around the Atmel AVR8515, primarily because I just wrote a test routine for it (linked, see below) and because it's really pretty typical of most microcontrollers.

By EEPROM, I mean memory within the micro, that is held without power, indefinitely, and is re-writable under program control. Much of this is also applicable to external EEPROM chips, but there are several versions of terminology out there.

There are a few things that you must do, when using EEPROM memory in a micro.

See also:

From SStef Mientki at http://oase.uci.kun.nl/~mientki/pic/libs_hw/eeprom_problems.html

In december 2004 an interesting discussion took place about an often overseen spec of the EEprom.

I too have done a project that has probems probably due to this phenomene. I even have written a library to increase the EEprom endurance, by spreading the information over the complete EEprom, but which offences against this rule and make things probably worse.

What's the problem ?
Normal endurance (parameter D124) is worst case 10^6 (upto 85 Celcius).

But writing to some place in EEprom, reduces the endurance of the other EEprom locations by
- a factor 10, (parameter D120) upto 85 Celcius
- a factor 100, (parameter D120A) above 85 Celcius

So my conclusion is that I've to write a new library, not spreading the information over the EEprom, but keeping the number of writes into a counter and create a refresh of the total EEprom when counter exceeds a certain value.

from m'chip techsupport

The data sheet is being updated in this area.

The refresh works as follows:

Refresh means you read and re-write the little used cells before the entire array sees 10Million writes.

The ultimate endurance of the DATA EEPROM memory is (size * cell Endurance).  However if you never touch one address you can expect that one address to be corrupted before you reach the ultimate endurance.  That is why we recomend periodic refresh of less frequently used memory locations.

from Bob Ammerman:

Basically the issue is this:

Any write to EEPROM memory (any location) degrades the signal stored in _all_ EEPROM locations. Thus, the value of any given location can be corrupted, if there are too many writes to _other_ locations between writes to that location.

The datasheet will define parameters for this. For many, but not all PICs, these parameters are called D120 and D120A.

For an example, looking at the datasheet for the PIC18F1220/PIC18F1320 we find (marked as advance information in the copy I have):

Parameter D120 - Byte Endurance - Min=100K, Typ=1M -- This is the number of times any single byte of EEPROM can be written to reliably.

Parameter D124 - Number of total ERASE/WRITE cycles before refresh - Min = 1M, Typ = 10M -- Any bytes that have _not_ been written need to be refreshed before D124 total writes to other bytes are done.

So, what does this really mean?

Well, if you do less than 1M total writes to the EEPROM (and 100K to any one byte) in the life of your product, you have no problem.

If you are using some sort of logging scheme where every EEPROM cell you are using is written to 'regularly', you have no problem.

The typical case where you do have a problem is where some EEPROM locations are quite static and seldom written, while others are actively written. A primary example of this is where configuration or calibration data is stored in part of the EEPROM and logged data in the rest. In this case you would have to perform a periodic refresh of the configuration/calibration data (before doing 1M writes to the logging data area).

A refresh, of course, is as simple as reading and then immediately rewriting the same memory location with the same value.

One useful way to avoid the refresh issue is to store your configuration/calibration data in program memory on those PICs that support self writing. This will work if you can live within the endurance constraint of program memory (parameter D130 for our example PICS, Min=10K, Typ=100K), and can afford to have your PIC 'freeze' while writing the parameters.

Comments: