Minimum voltage to avoid EEPROM corruption for ATMega328P

Question

I have a battery powered contraption with an ATMega328P with Arduino code that sleeps most of the time. Occasionally it needs to write some values to EEPROM. It's battery powered so I have tried to minimize the consumption by disabling the BOD, so now I'm curious around what voltage range the EEPROM might become damaged. Has anybody tried to see how low one can lower the voltage and still have it safe?

In the datasheet I see there are options for BOD at 1V8. Does that mean that it would be safe to write EEPROM at 2V?

Answer 1

I've been reading up on AVRs myself; I'm not the most knowledgeable, but this is what I've picked up in my research.

First, I realize you are disabling your BOD to save power, but this is listed as a preventative method to avoid EEPROM corruption in the ATmega328P. From section 8.4.2:

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 you are really keen on disabling the BOD, it is possible to have it disabled when in sleep mode. To accomplish this, you can set the BODS bit in the MCUCR register.

Like you, I have become frustrated with the ambiguity in the voltage which at which the AVR's EEPROM will become corrupted. I see nothing in the datasheet. However quoting Atmel's EEPROM Corruption article on their website:

a regular write sequence to the EEPROM requires a minimum voltage to operate correctly

Minimum voltage? This is a generic article, so I'd guess this refers to the lowest voltage at which the ATmega328P operates at, which is 1.8V.

Hope I've helped.

Answer 2

As an addition to the accepted answer:

Regardless of the causes for EEPROM corruption, you always face the potential problem that you are not able to complete writing a sequence of bytes.
Consider a 4-Byte integer value. The BOD will only "guarantee" that single byte corruption won't happen, however it won't prevent the controller from shutting down before the whole 4-byte value has been written, effectively corrupting your data.

To be on the safe side you have to implement some kind of "commit" mechanism. This would involve a checksum to verify that you data is valid and a mirror copy of the data, to make sure that one dataset is always valid. If the checksum fails on startup, you can fall back to the backup. The "valid and active" dataset can be "marked" with a single byte.

Answer 3

This is in no way a guarantee, just my personal experience.

The datasheet provides a safe operating area based on clock speed and voltage. Its boundary drops from 4.5V at 20 MHz to 2.7V at 10 MHz.

However, as one of our systems has power interruptions and brownouts several times a second by design, I had the opportunity to observe its behavior under conditions when brownout is a regular event. Running on 20 MHz with a BOD-level of 1.8 V eeprom corruption happened fairly regularly, especially on unclean startups. Setting it to 2.7 V solved this, and eeprom corruption never occurred above 2.7 V. (in the datasheet it's still not in the safe operating area, so use it on your own risk) When using it with the 8 Mhz internal oscillator, the 1.8 V BOD-level was enough, eeprom corruption did not occur.