# “Overclocking” an AVR

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?

-
If you only run it sortof in spec, then it will only sortof work. – Olin Lathrop Oct 31 '11 at 15:33
May seem dumb but couldn't you replace the XTal? – Hossein Oct 31 '11 at 20:11

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 belooked up correctly.
• An ADC value may be correct.

Or not

-
i love this answer lol – vicatcu Oct 31 '11 at 16:36
This is marvellous. – Andrey Vihrov Oct 31 '11 at 20:45
Actually, if you have a $10 head, you should buy a$10 * probability_of_catastrophic_failure helmet. – Nick Johnson Nov 1 '11 at 6:18
@NickJohnson - :-). | That was an (I think) Bell Helmets Ad from long log long ago (may still be current?) so I can't change the words :-). – Russell McMahon Nov 1 '11 at 12:56
This answer is perfect, in true freehand circle fashion. – jamuraa Nov 3 '11 at 5:10
show 1 more comment

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.

-
It would be good to note that armoring EEPROM writes merely makes complete bricking of the device statistically less likely, it doesn't do much to make errant execution any less likely. Nonetheless, it seems like a good policy. I'm startled that 9 nines of reliability has such a high probability of failure in one minute at just 16 MHz. – Kevin Vermeer Oct 31 '11 at 15:30
@Kevin Vermeer: It's often difficult to ensure that a device will never operate out of its safe operating region, given the possibilities of power supply sags, electrostatic events, etc. The EEPROM-armoring isn't designed to make errant execution more likely--it's illustrative of how to minimize the consequences. Similar techniques are often useful for code which operates external hardware. One shouldn't rely on code for safety-critical systems, but in e.g. a label-maker one might use logic like the above to guard the label-feed controls, so random execution won't destroy \$5 in label stock. – supercat Oct 31 '11 at 15:39
To be clear, I'm talking specifically about Atmel AVR microcontrollers - which are very different from general purpose processors... – vicatcu Oct 31 '11 at 15:43
@vicatcu: Is there some particular way you're thinking of that they're different from the PIC, 8x51, 68HC05, ARM, etc.? Or for that matter, older CPUs like the 6502 or Z80? On modern CPUs, overclocking can cause self-destructive overheating, but on smaller or slower CPUs, that is a non-issue at any speed where the device would have any chance of working. – supercat Oct 31 '11 at 20:13

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

-
 given that it does work at some voltage/temperature (3.3V and 25C), does the clock just operate along the boundary rather than the crystal's rated frequency? "might not work" is awefully vague... – vicatcu Oct 31 '11 at 15:46 @vicatcu - "Awfully vague is EXACTLY* the spec you get. "Might not work" is **EXACTLY the spec. ON the boundaries will work. So you can be sure that there is some safety margin. How big? Make their day ... – Russell McMahon Oct 31 '11 at 16:35 haha yea, I never design out of spec, I was asking this to be a bit provocative – vicatcu Oct 31 '11 at 16:38 @vicatcu: Sometimes it seems almost impossible to avoid designing at least nominally out of spec. For example, if two devices specify VOut(Max) and VIn(Max) both as VDD, and one connects an output of each to an input of the other, the even if they're wired up to the same rail I don't see how one could guarantee that a momentary current transient in one device couldn't cause its VDD to fall a even a microvolt below the voltage output by the other device. If it did so, that could exceed the specified operating condition that the input must not exceed VDD. – supercat May 7 at 15:34 @vicatcu: Of course, I think most engineers would figure that the way the devices are physically constructed would almost guarantee the existence of at least a few millivolts' tolerance on such things, but many data sheets don't specify any. Not sure why. I can understand a manufacturer not wanting to specify anything close to what today's parts will accept without problem, but specifying something would seem nicer than not specifying anything. – supercat May 7 at 15:37