Is your program using address 0 of the eeprom? If it is, change your code to begin @0x0001 in the eeprom.
In some AVR devices, when the reset activates during a write to the
internal EEPROM, the EEPROM Address Register will be set to zero (0x000).
The result may be seen as corruption of both the location being written, and
of location zero (0x000).
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 counter could conceivably 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.
Here are some other appnotes to read:
**broken link removed**
https://www.electro-tech-online.com/custompdfs/2009/03/doc1051.pdf
What i would do is program the code in the avr,
and do not program lock bits. Run it in your circuit until the corruption happens. (power the circuit up & down many times until it happens, it will happen) Then read the eeprom to see exactly which location is being erased or corrupted. I'll be willing to bet its location 0x0000 in the eeprom, I have seen it many times before. It usually happens upon startup, while voltage is still climbing, or not at its peak.
I once wrote a small routine to read location 0x0000 in the eeprom (at startup), if it was 0x00, re-store the data to a default setting (just so the flash would not have to be re-programmed) This would allow the program to repair itself and proceed, whenever an error should occur.