please dont rip this site

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

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.


file: /Techref/mem/eeprom/corruption.htm, 10KB, , updated: 2010/10/1 20:34, local time: 2018/1/18 01:32,

 ©2018 These pages are served without commercial sponsorship. (No popup ads, etc...).Bandwidth abuse increases hosting cost forcing sponsorship or shutdown. This server aggressively defends against automated copying for any reason including offline viewing, duplication, etc... Please respect this requirement and DO NOT RIP THIS SITE. Questions?
Please DO link to this page! Digg it! / MAKE! / 

<A HREF=""> EEPROM Memory Corruption</A>

After you find an appropriate page, you are invited to your to this massmind site! (posts will be visible only to you before review) Just type in the box and press the Post button. (HTML welcomed, but not the <A tag: Instead, use the link box to link to another page. A tutorial is available Members can login to post directly, become page editors, and be credited for their posts.

Link? Put it here: 
if you want a response, please enter your email address: 
Attn spammers: All posts are reviewed before being made visible to anyone other than the poster.
Did you find what you needed?

  PICList 2018 contributors:
o List host: MIT, Site host, Top posters @20180118 David C Brown, Isaac M. Bavaresco, Manu Abraham, Van Horn, David, RussellMc, Harold Hallikainen, James Cameron, Sean Breheny, Allen Mulvey, Dwayne Reid,
* Page Editors: James Newton, David Cary, and YOU!
* Roman Black of Black Robotics donates from sales of Linistep stepper controller kits.
* Ashley Roll of Digital Nemesis donates from sales of RCL-1 RS232 to TTL converters.
* Monthly Subscribers: Gregg Rew. on-going support is MOST appreciated!
* Contributors: Richard Seriani, Sr.

Welcome to!