user190: ATMEL says the cell lifetime of an EEPROM cell is about 100,000 write cycle/ cell.
Is this actually how the EEPROM performs in the wild?
If I do not change the value of a cell, does this stress the lifetime? For example, if I write the value 0xFF to the same cell again and again, is this any different to writing 0x00, 0xFF, 0x00 etc.

user62038: Couple years ago I made run time logger for piece of equipment.  Memory got corrupted after 6 months 40 hours logged with 1s resolution => 144000 writes. 
My solution was to spread writes over entire eeprom.

user160: http://hackaday.com/2011/05/16/destroying-an-arduinos-eeprom/

The Arduino was plugged into a wall wart and sat, “behind a couch for a couple of months.” The EEPROM saw it’s first write error after 47 days and 1,230,163 cycles. This is an order of magnitude better than the spec on the atmel datasheet, but similar to the results of similar experiments.


user61144: The magic solution - if you dont want to code what Cybergibbons said about reading before writing, is the EEPROM.update() function. It does exactly that: 
EEPROM.update(address, value);
will only write and stress the memory if value is different from that already stored.

user8: I once ran an experiment on an external EEPROM with 1 million max rated cycles. It took about 6 million cycles to become majorly corrupted, and before that it had progressed having sporadic amounts of corruption. 
When you say you do not change the value, i am assuming you are writing the same data to an address multiple times. This almost certainly would stress the life, although it would probably not stress the surrounding cells.

user136: As you state, the internal EEPROM has a lifetime of 100,000 write cycles. This isn't a guess - a very significant proportion of ATmega328 will reach this number with no issues. I have tested three processors before, and all reached 150,000 cycles with no issues.
It is important to note the failure mode of EEPROM. Most "EEPROM destroyer" projects repeatedly read/write until the data is not written at all. Before this point, the EEPROM will still be damaged. This would be manifested by data not being retained for a reasonable period. It is unwise to rely on anything more than 100,000 write cycles for this reason.
EEPROM is different to the RAM on an ATmega. Writing to it is not simple or quick, but it is wrapped up in a friendly Arduino library, hiding this complexity from the user.
The first level of indirection is the EEPROM library, which is trivially simple], just calling two other functions for read and write. This calls eeprom_write_byte, found here.
This function uses inline assembly, so might not be easily understood. There is a comment that is easily understood though:

Set programming mode: erase and write

This hints to one of the complexities of dealing with EEPROM - to write to
it, you first need to erase it. This means that if you call EEPROM.write(), it will perform a write cycle regardless of the value you are writing.
This means that repeatedly writing 0xFF will likely have the same effect as writing 0xFF,0x00,0xFF,0x00 etc.
There are ways to work around this - you can try calling EEPROM.read() before EEPROM.write() to see if the value is already the same, but this takes additional time. 
There are other techniques to avoid excessive EEPROM wear, but their use depends on your application.

190: <p>ATMEL says the cell lifetime of an EEPROM cell is about 100,000 write cycle/ cell.
Is this actually how the EEPROM performs in the wild?</p>

<p>If I do not change the value of a cell, does this stress the lifetime? For example, if I write the value <code>0xFF</code> to the same cell again and again, is this any different to writing <code>0x00</code>, <code>0xFF</code>, <code>0x00</code> etc.</p>
 62038: <p>Couple years ago I made run time logger for piece of equipment.  Memory got corrupted after 6 months 40 hours logged with 1s resolution => 144000 writes. 
My solution was to spread writes over entire eeprom.</p>
 160: <p><a href="http://hackaday.com/2011/05/16/destroying-an-arduinos-eeprom/" rel="nofollow">http://hackaday.com/2011/05/16/destroying-an-arduinos-eeprom/</a></p>

<blockquote>
  <p>The Arduino was plugged into a wall wart and sat, “behind a couch for a couple of months.” The EEPROM saw it’s first write error after 47 days and 1,230,163 cycles. This is an order of magnitude better than the spec on the atmel datasheet, but similar to the results of similar experiments.</p>
</blockquote>
 61144: <p>The magic solution - if you dont want to code what Cybergibbons said about reading before writing, is the EEPROM.update() function. It does exactly that: </p>

<p>EEPROM.update(address, value);</p>

<p>will only write and stress the memory if value is different from that already stored.</p>
 8: <p>I once ran an experiment on an external EEPROM with 1 million max rated cycles. It took about 6 million cycles to become majorly corrupted, and before that it had progressed having sporadic amounts of corruption. </p>

<p>When you say you do not change the value, i am assuming you are writing the same data to an address multiple times. This almost certainly would stress the life, although it would probably not stress the surrounding cells.</p>
 136: <p>As you state, the internal EEPROM has a lifetime of 100,000 write cycles. This isn't a guess - a very significant proportion of ATmega328 will reach this number with no issues. I have tested three processors before, and all reached 150,000 cycles with no issues.</p>

<p>It is important to note the failure mode of EEPROM. Most "EEPROM destroyer" projects repeatedly read/write until the data is not written at all. Before this point, the EEPROM will still be damaged. This would be manifested by data not being retained for a reasonable period. It is unwise to rely on anything more than 100,000 write cycles for this reason.</p>

<p>EEPROM is different to the RAM on an ATmega. Writing to it is not simple or quick, but it is wrapped up in a <a href="http://arduino.cc/en/Reference/EEPROM#.Uv8RdHnG">friendly Arduino library</a>, hiding this complexity from the user.</p>

<p>The first level of indirection is the <a href="https://github.com/arduino/Arduino/blob/598ab1d5c003e02b6bb193640fac8526ad8ab912/libraries/EEPROM/EEPROM.cpp">EEPROM library</a>, which is trivially simple], just calling two other functions for read and write. This calls eeprom_write_byte, found <a href="https://github.com/arduino/Arduino/blob/598ab1d5c003e02b6bb193640fac8526ad8ab912/build/windows/eeprom.h">here</a>.</p>

<p>This function uses inline assembly, so might not be easily understood. There is a comment that is easily understood though:</p>

<blockquote>
  <p>Set programming mode: erase and write</p>
</blockquote>

<p>This hints to one of the complexities of dealing with EEPROM - to write to
it, you first need to erase it. This means that if you call EEPROM.write(), it will perform a write cycle regardless of the value you are writing.</p>

<p>This means that repeatedly writing 0xFF will likely have the same effect as writing 0xFF,0x00,0xFF,0x00 etc.</p>

<p>There are ways to work around this - you can try calling EEPROM.read() before EEPROM.write() to see if the value is already the same, but this takes additional time. </p>

<p>There are other techniques to avoid excessive EEPROM wear, but their use depends on your application.</p>
