wow!
Atmel emailed me a user password for their support site in about two seconds, and I immediately found this document on how to corrupt your eeproms! Although ( I am not completely sure if by EEProm they are referring to the small eeprom or the larger flash memory.)
I have to run at the moment, but I leave you this juicy tidbit for your perusal:
EEPROM corruption
Question
My EEPROM is sometimes corrupted, what can I do to prevent this?
Answer
During periods of low VCC, the EEPROM data can be corrupted because the
supply voltage is too low for the CPU and the EEPROM to operate properly.
These issues are the same as for board level systems using EEPROM, and the
same design solutions should be applied.
An EEPROM data corruption can be caused by two situations when the voltage
is too low. First, a regular write sequence to the EEPROM requires a minimum
voltage to operate correctly. Second, the CPU itself can execute
instructions incorrectly, if the supply voltage is too low.
EEPROM data corruption can easily be avoided by following this design
recommendation:
Keep the AVR RESET active (low) during periods of insufficient power supply
voltage. This can be done by enabling the internal Brown-out Detector (BOD).
If the detection level of the internal BOD does not match the needed
detection level, an external low VCC Reset Protection circuit can be used.
If a reset occurs while a write operation is in progress, the write
operation will be completed provided that the power supply voltage is
sufficient.
What all this means is: If you can't guarantee power, you have to make sure
that the part is kept in RESET when it is outside of spec. You can do this
using the internal BOD, but this will not take care of the case when an
EEPROM write has already began when the part loses power. Thus you must also
make sure to write to the EEPROM only when you're sure to have power.
It is not enough to write to the EEPROM during "safe periods" and leave the
BOD disabled, though: If the part gets outside spec it can begin executing
erratically, and the program couter could concievably jump to the part in
the code in which the EEPROM is written.
These are not bugs but intrinsic demands of the EEPROM.
Interrupts are not disabled automatically, but the customer is urged to take
care of the following during EEPROM write (the order of steps 3 and 4 is not
essential):
1. Wait until EEWE becomes zero.
2. Wait until SPMEN in SPMCR becomes zero.
3. Write new EEPROM address to EEAR (optional).
4. Write new EEPROM data to EEDR (optional).
5. Write a logical one to the EEMWE bit while writing a zero to EEWE in
EECR.
6. Within four clock cycles after setting EEMWE, write a logical one to
EEWE.
Caution: An interrupt between step 5 and step 6 will make the write cycle
fail, since the EEPROM Master Write Enable will time-out. If an interrupt
routine accessing the EEPROM is interrupting another EEPROM access, the EEAR
or EEDR Register will be modified, causing the interrupted EEPROM access to
fail. It is recommended to have the Global Interrupt Flag cleared during all
the steps to avoid these problems.
Edit: I just checked the bootloader tutorial in the Playground, and it says to use the following settings for the Atmega168 ( this needs to be confirmed with Massimo or Gianluca);
Brown-out detection disabled; [BODLEVEL=111]
This certainly sounds like a likely answer to the problems you're experiencing, if the BOD fuse settings above are the ones in use.
Also, you said above that you are using some kind of surge-suppressor on the DC line. If this is on the DC input side of the Arduino, these contain inductors that slow the voltage rise; might be worth checking out.
D