The EEPROM address 0 is indeed a problem in some older Atmel parts.
I've actually received confirmation of the problem from the local FAE.
I've also received confirmation that it's not a problem with the
ATmega48/88/168 series.

Apparently, there are some processors that have registers set to cause
an EEPROM write to byte 0 as they power-up.  Once you get past the
power-up sequence, EEPROM byte 0 is safe to use.

To avoid this problem, the IAR and ImageCraft C compilers will not
allocate EEPROM data to byte 0.  Unfortunately, both compilers do this
independent of the processor type.

-Mike
 
> From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On
Behalf
> Of David VanHorn
> Sent: Wednesday, August 09, 2006 2:52 PM
> 
> On 8/9/06, Mike Hord <mike.hord@gmail.com> wrote:
> >
> > So, it turns out that the ATMega128 seems to be quite susceptible
> > to the EEPROM address 0 correction bug which has plagued
> > Atmel in the past.  Atmel just hasn't acknowledged it, or deemed
> > it fit information to put into their errata.
> 
> 
> How did you ascertain that?
> 
> I have, for many years, left location 0 as a "sacrificial goat", with
the
> EEAR pointing there on exit from any read or write, so that any
accidental
> operation would not corrupt my data.
> 
> Years past, I wrote some firmware for the 8515 specifically looking
for
> any
> EE corruption, and never did find any.
> 
> People frequently miss some of the constraints of modifying EE or
> codespace,
> and think that there is a chip problem, when there is not.
> Things like when power dissapears, and when reset can occur..
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist