I love microcontrollers but sometimes they drive me )$*(@! nuts.
Here are some of the things that you can look for when you're having microcontroller problems
WinAVR is great, better than AVR studio but there's no nice fuse selector like there is with AVR studio. Luckily there are two calculators
OK so you messed up, and now your internal oscillator design is running so slowly (say 32Khz or something) that your programmer is too fast! Now what? Lucky for you, Evil Mad Scientist Labs has figured it out:
So, let's assume that you've set your AVR clock source to a very slow internal signal, and you can no longer program the device by conventional means. It is still possible at that point to use avrdude in interactive mode by entering a command like the following:
avrdude -p t2313 -c avrispmkII -P usb -tuF
where "t2313," "usb," and "avrispmkII" should be changed as needed to reflect your device, interface/programmer location, and programmer.
Once it (finally) enters interactive mode (at its super-slow clock speed), enter "sck 1000" at the prompt. This slows down the serial communication greatly by setting the SCK signal period to 1000 microseconds. You can then erase the chip by entering "e" and then set the programmer back to normal by entering "sck 10" (for a 10 microsecond period). Finally, enter "quit" to exit interactive mode. Your chip should be back to normal at this point, which you can verify by programming it again– hopefully without the same fuse bit settings.
You can also use the Atmel Dragon, or the Atmel STK500 and High-Voltage programming to reset the clock (or other) fuses.
Don't forget, the 2 extra A/D pins on the QFP packages of Atmega8, '88, '48, and '168 can't be used as general purpose I/O!
If you have a bootloader (or use spm some other way) you must set the brownout fuses. Hidden in the AVR datasheets is this warning:
Preventing Flash Corruption: During periods of low VCC the Flash program can be corrupted because the supply voltage
is too low for the CPU and the Flash to operate properly. These issues are the same
as for board level systems using the Flash, and the same design solutions should be
A Flash program corruption can be caused by two situations when the voltage is too low.
First, a regular write sequence to the Flash requires a minimum voltage to operate correctly.
Secondly, the CPU itself can execute instructions incorrectly, if the supply voltage
for executing instructions is too low.
Flash corruption can easily be avoided by following these design recommendations (one
If there is no need for a Boot Loader update in the system, program the Boot Loader Lock bits to prevent any Boot Loader software updates.
Keep the AVR RESET active (low) during periods of insufficient power supply voltage. This can be done by enabling the internal Brown-out Detector (BOD) if the operating voltage matches the detection level. If not, an external low VCC Reset Protection circuit can be used. If a Reset occurs while a write operation is in progress, the write operation will be completed provided that the power supply voltage is sufficient.
Keep the AVR core in Power-down sleep mode during periods of low VCC. This will prevent the CPU from attempting to decode and execute instructions, effectively protecting the SPMCR Register and thus the Flash from unintentional writes.
So make sure to always use BOD fuses!
Brownouts can cause the first location of the on-board EEPROM to be overwritten.
In addition to the precautions elsewhere on this Wiki, consider not using the first EEPROM location.
If the voltage on your chip goes too low it can start executing random instructions, or corrupt the flash/eeprom (see above) so just always set the BOD unless there's some good reason not to!
Not really an annoyance, but just so you know: Unless your design is in an electrically noisy environment, it is not necessary to have a pull-up 10K (or whatever) resistor on the Reset pin, there's an internal one already!
(Reference: see "DC characteristics" of any AVR datasheet for R_RST 20-100Kohm pull up resistor)
For a solid design, follow AVR app note AVR040's suggestions: "To achieve the same protection on Reset as on other I/O pins, an external diode should be connected from Reset to VCC. A normal small-signal diode will do [ed. 1N914 or 1N4148]. In addition, a pull-up resistor (10K typical) and a small filter capacitor (4.7 nF) should be connected as shown in Figure 4-7."
Note: AVR042 has more info on reset pin design (as well as overall good advice for hardware design w/AVRs)
If you plan to use debugWIRE, the resistor to VCC should be 10K or larger, and there should not be a capacitor to ground. See page 4 of AVR042 for details.
Even if you don't use the A/D converter, AVCC must be tied to VCC
The attinys in the 8 SOIC package are 8 SOIC Wide, so programmer clips (which are almost always for 8SOIC Narrow) may not fit onto them without adjustments.
Some chips' datasheets may refer to DI/DO instead of the 'standard' MISO and MOSI programming pins
Similarly, the atmega128 uses 'nonstandard' pins for programming: Check the datasheet under "SPI Serial Programming Pin Mapping" to discover you should use the following for programming: MOSI → PE0, MISO → PE1, SCK → PB1 — AVR Wiki
On some (all?) AVRs, if the SPI slave select (SS_) pin is an input and low, then the SPI interface will go into slave mode, even if you have previously selected master mode. Hope you weren't using that pin for something else.
Don't forget: pin RA4 is almost always open collector: that means that it can only 'float' or sink current!
( Do we link to other sites? ) This page is excellent: Microchip Technologies Gotchas