"Overclocking" an AVR

Question

In AVR datasheets under the Electrical Characteristics section you will typically find a graph like this (this one is from the ATMega328):

I've seen designs that seem to "work" but operate outside the shaded envelope. Specifically, I've seen 3.3V (Arduino) designs that run the clock from an external 16MHz crystal. Clearly, this is out of spec. What are the practical negative consequences of running outside this envelope?

Answer 1

How to make life more interesting 101:

• If you don't care

that your results may sometimes be wrong,
that your system may sometimes crash,
that your life may be more interesting,
that your Segway clone only occasionally does face-plants for no obvious reason,
that ...

Then by all means run the part outside manufacturer's spec.

You get what you don't pay for.
If you have a $10 head, buy a $10 helmet.

• It may often work.
• It may not work sometimes.
• It may not be obvious that it isn't working sometimes.
• A divide may usually work
• A jump may usually arrive.
• A table may be looked up correctly.
• An ADC value may be correct.

Or not

Answer 2

At these sorts of speeds, most processors work by computing all of the signals that will be needed at a certain clock cycle, waiting for the next clock edge while they stabilize, latching all of those signals and computing the signals needed at the next clock cycle, waiting for that edge while those signals stabilize, etc. If a clock edge arrives before the necessary signals have stabilized, the effect will be that whichever signals hadn't stabilized may not be latched cleanly. If this occurs in a microcontroller, the effects may be unpredictable--for at least two reasons:

1. In many cases, execution speed is limited by the response time of the flash array from which the processor reads code. If running the processor too fast causes an occasional bit to be misread here or there, it could easily cause the processor to execute entirely different code from what was intended. In many programs, even a one-time single-bit misread could radically alter the behavior; it is seldom practical to try to make any predictions about what might happen in such cases. The best one can do in some cases is "armor" certain parts of the program so as to make errant execution unlikely. For example, one might leave an EEPROM protected until one wants to write it, and then use code something like:

   uint32_t eep_checksum, eep_addr, eep_data;
   
   #define EEPROM_WRITE(address, data, predicate) \
     eep_checksum = 0xC0DEFACE, eep_addr = (address), eep_data = (data), \ 
     eep_checksum += eep_addr + eep_data, ((predicate) || HARD_CRASH()), \
     eep_checksum += (0xCAFEBABE - C0DEFACE), eep_do_write()
   
   void eep_do_write(void)
   {
     ENABLE_EEPROM_WRITE_HARDWARE();
     if (eep_checksum != eep_addr + eep_data + 0xCAFEBABE)
     {
       DISABLE_EEPROM_WRITE_HARDWARE();
       HARD_CRASH();
     }
     DO_EEPROM_WRITE();
     DISABLE_EEPROM_WRITE_HARDWARE();
   }  
   

   It is very unlikely that an eeprom_write routine will attempt to write data unless the "eep_checksum = 0xC0DEFACE" is executed before the address and data are loaded. Following the execution of that, the predicate will be checked for validity before adjusting the checksum to the proper value and calling the eeprom_store routine.
2. In addition to the clear risks posed by executing incorrect code, another source of potential random behavior is metastability. Normally, on any cycle, every flip flop will latch either a high or low. If, however, the input to a flip flop changes just as the clock arrives, it may for some arbitrary duration output weird stuff which may arbitrarily flip between high and low, in any pattern, until the next clock cycle; it is entirely possible that some devices downstream from the flip flop will see it as "high" while others see it as "low". Generally, processors rely upon many devices agreeing on what they're going to do. If during the execution of a "decrement-and-branch-if-not-equal" instruction, and some circuits think the branch should be taken but others don't, the processor may fall into a really weird state.

Manufacturers specify operating parameters for processors such that, within those parameters, the processors will just plain work. Pushing things outside that envelope may reduce the processor to only being 99.9999999 reliable. That may not sound too evil, but trying to diagnose a processor which does something arbitrarily wrong once a minute or so (figuring 16MHz) is no fun.

Answer 3

Simplified answer for your question:

Working outside "safe speed area" may cause your system work unstable. What that means? Wrong calculation results, microcontroller resets etc.

If you want to do that for just fun, you should take a look at these pages/articles:

Overclocking Arduino with liquid nitrogen cooling. 20⇒65.3Mhz @-196°C/-320°F

ATmega328 Overclock (30MHz)

Answer 4

One consideration not mentioned yet, which is less to do with operating at valid frequencies in invalid voltage ranges (16MHz at 3.3V) but more to do with running at invalid frequencies at valid voltage ranges (24MHz at 5V) is that of heat dissipation.

Every time a gate in the chip switches on or off it dissipates heat. The gate, being made up of MOSFETs, acts like a variable resistor in the period between being ON and OFF, or OFF and ON. That resistor of course dissipates heat. The more frequently it switches the less time there is between switchings for that heat to dissipate out of the chip, and you risk heat buildup.

Ergo, the faster you run, the more heat can build up. That is why PC CPUs have big fans on them - they switch so fast they can't get the heat out of the chip fast enough, so they need help.

The top rated speed of the chip is selected to allow the chip to dissipate its heat buildup reliably under the valid operating conditions (i.e., the ambient temperature, typically max 85°C or 105°C for example). Exceeding that frequency can cause the chip to overheat.

Yes, it can be possible to run the chip faster than intended if you provide some assistance - i.e., a heat sink and maybe a fan, and ensure there is good airflow around it. But of course, on a warm day in summer you may find what was a perfectly working device all winter suddenly starts doing strange things.

Another thing to consider is that of slew rates. Clock signals (and other signals too) take time to rise or fall to their desired level. If the internals of the chip mean the clock signal takes say 15ns to rise from a LOW to a HIGH, and you try and clock it at a frequency where a HIGH period is, say 42ns (24MHz), that leaves only 27ns of valid clock period left. That's just 64% of the clock actually being a clock signal - the rest is rubbish. The same for IO pins. Things like SPI clock outputs will be limited by the slew rate of the IO pin, so if you overclock your chip to get faster SPI you will find things don't always go as planned, as the nice square wave you expect from the clock output isn't square any more.

Answer 5

The device might not work at some voltage/temperature combination.