Brown-out detection with an external clock ATmega1280

Thread Starter


Joined Jun 22, 2020
I'm using ATmega1280 with an external clock and I have some questions about the "safe operating area" for preventing EEPROM corruption with BOD.
The external clock is: Crystals 14.7456MHz 18pF HC49S SMD by CITIZEN, without clock division.
LINK to ATmega1280 datasheet

In the datasheet of ATmega1280 the flash and EEPROM unit gets two clock arrows as below: (page 39)
and the "safe operating area" is: (page 358)
The line is linear between 2.7V and 4.5V, so according to this figure I'm supposed to be above 4.21V to be in the safe zone, but my Vcc is 3.3V and the system works great without any problems. what I'm missing? this graph is for the internal clock? (page 359)
How do I need to calculate my safe zone according to my external clock?


Joined Feb 24, 2006
What the datasheet is trying to tell you is that you are skating on thin ice. Just because you have a particular unit that works well under the stated conditions does not mean that a part will not come to you that is within spec according to the datasheet but will not work in your situation. Atmel (now Microchip) writes a datasheet so that 99.6% of the parts that come off the line meet the conditions. This insures that folks who make large numbers of identical boards won't end up with a box of chicklets. This is the same reason that some high end Intel processors can be over-clocked. I'm not sure if the Safe Operating Area has anything to do with EEPROM corruption in a brownout. I think it has more to do with will the processor fetch and execute instructions without going off into the weeds.

schmitt trigger

Joined Jul 12, 2010
I can tell you, that in a mid-large volume application, which employed a very similar Atmega microcontroller, which operated in the "thin-ice-zone" described by Papabravo, there were corrupted EEPROM field failures.

Not very many, but enough to create customer dissatisfaction.


Joined Feb 24, 2006
All CMOS processes have a delicate balance between speed, Vcc, and power consumption. Trying to compromise in one area pushes like a see-saw on something else. Is running a 14.7456 MHz. a necessity or could you cut the frequency in half and still get your baudrate clocks correct?