"Overclocking" an AVR

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

enter image description here


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.


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)

Tags:

Microcontroller

Arduino

Avr

Clock Speed

Recent Posts