Recent AVR-LibC FAQ submission of mine:
Why are some address of the AVR EEPROM corrupted? Usually address zero.
The two most common reason for EEPROM corruption is either writing to the EEPROM beyond the datasheet endurance specification, or resetting the AVR while a EEPROM write is in progress.
EEPROM writes can take up to tens of milliseconds to complete. So that the CPU is not tied up for that long of time, an internal state-machine handles EEPROM write requests. The EEPROM state-machine expects to have all of the EEPROM registers setup, then a EEPROM write request to start the process. Once the EEPROM state-machine has started, changing EEPROM related registers during a EEPROM write is guaranteed to corrupt the EEPROM write process. The datasheet always shows the proper way to tell when a write is in progress, so that the registers are not changed by the user's program. The EEPROM state-machine will always complete the write in progress unless power is removed from the device.
As with all EEPROM technology, if power fails during a EEPROM write the state of the byte being written is undefined.
In older generation AVR's the EEPROM Address Register (EEAR) is initialized to zero on reset, be it from Brown Out Detect, Watchdog or the Reset Pin. If a EEPROM write has just started at the time of the reset, the write will be completed, but now at address zero instead of the requested address. If the reset occurs later in the write process both the requested address and address zero may be corrupted.
To distinguish which AVR's may exhibit the corrupt of address zero while a write is in process during a reset, look at the "initial value" section for the EEPROM Address Register. If EEAR shows the initial value as 0x00 or 0x0000, then address zero and possibly the one being written will be corrupted. Newer parts show the initial value as "undefined", these will not corrupt address zero during a reset (unless it was address zero that was being written).
EEPROM's have limited write endurance. The datasheet specifies the number of EEPROM writes that are guaranteed to function across the full temperature specification of the AVR, for a given byte. A read should always be preformed before a write, to see if the value in the EEPROM actually needs written, so not to cause unnecessary EEPROM wear.
AVR's use a paging mechanism for doing EEPROM writes. This is almost entirely transparent to the user with one exception: When a byte is written to the EEPROM, the entire EEPROM page is also transparently erased and (re)written, which will cause wear to bytes that the programmer did not explicitly write. If it is desired to extend EEPROM write lifetimes, in an attempt not to exceed the datasheet EEPROM write endurance specification for a given byte, then writes must be in multiples of the EEPROM page size, and not sequential bytes. The EEPROM write page size varies with the device. The EEPROM page size is found in the datasheet section on Memory Programming, generally before the Electrical Specifications near the end of the datasheet.
The failure mechanism for an overwritten byte/page is generally one of "stuck" bits, ie. a bit will stay at a one or zero state regardless of the byte written. Also a write followed by a read may return the correct data, but the data will change with the passage of time, due the EEPROM's inability to hold a charge form the excessive write wear.
