# “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
• Not a good idea, most chances it will not work and anyway you gain very little from adding under 1 MIPS to a 20 MIPS processor, above that I'm 100% the AVR will crash. You must keep setup and hold times for the internal signals, the max freq. takes the worse case scenario in the most critical signal path inside the AVR, manufacturing variations might make one chip a bit more immune to overclocking but by very little and remember that even if the core itself runs fine it does not mean peripherals will or that you can replicate it with another chip from different batch. – user34920 Jul 5 '14 at 4:22
• To repurpose a joke: "If they'll pretend to clock us within spec, we'll pretend to work." – nitro2k01 Oct 3 '14 at 6:15
• This may be a dumb question, but I thought all AVR Arduinos ran at 5v, except the Mini Pro-3.3v which only runs at 8MHz... or is there a faster 3.3v model that I haven't seen? – Jules Feb 8 '18 at 18:02

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

• 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
• I found my new wallpaper – Rick_2047 Mar 30 '13 at 4:41
• This is genius: "If you don't care (...) that your Segway clone only occasionally does face-plants for no obvious reason" – Kamil Jul 5 '14 at 9:45

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;

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

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)

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.

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 '13 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 '13 at 15:37