This is an old revision of the document!
I love microcontrollers but sometimes they drive me )$*(@! nuts.
Here are some of the things that you can do when you're having microcontroller problems
WinAVR is great, better than AVR studio but there's no nice fuse selector like there is with WinAVR. 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.
Don't forget, the 2 extra A/D pins on the 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!
Not really an annoyance, but just so you know: its not necessary to have a pull-up 10K (or whatever) resistor on the Reset pin, there's an internal one already!
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 and datasheets refer to DI/DO instead of MISO and MOSI
Don't forget: pin RA4 is almost always open collector: that means that it can only 'float' or sink current!