A large proportion of the threads posted to this website are as a result of experiments with ISP and setting fuses

that have gone

wrong and left the chip in a state where it appears you can no longer do ISP any more.
The good news is that about 90% of the time you can easily recover from the situation you find yourself in, though there are some
"dangerous fuses" on some models of AVR which can make recovery a bit more tricky (but never impossible).
The usual "damage" is simply that you have changed the state of the CKSEL fuse bits. When you first take an AVR out of the packet
it's fuses are set so that when power is applied it will clock at about 1MHz from an internal RC oscillator (in some cases it is 1.2MHz
if the main clock is 9.6MHz, rather than the more normal 8MHz). The advantage of the chips being supplied in this way is that ISP
can only work when the CPU will clock with power applied, so with no external circuitry (apart from power) it's possible for your ISP
programmer to connect to and program the chip. The "accident" most people have is to inadvertently change the CKSEL fuses to
choose some form of external clock that isn't present. Now this could be that you really meant to use a crystal but you actually
wrote a combination of CKSEL fuse bits to select "external oscillator" - that is NOT a crystal and just connecting a crystal and a
couple of capacitors is not sufficient if "external oscillator" has been selected - the chip is waiting for a full-swing TTL square wave
to be applied and a crystal won't do.
If you have had such a "clock accident" then recovery is fairly simple. The chip is just waiting for a clock to be applied - so apply
one. Now you may say "but I don't have an external oscillator" but there are a number of things that can be done to provide the
clock that the chip is waiting for. In all cases this involves applying a clock signal to the XTAL1 pin of the chip where CKSEL was misset. This will be enough to have a successful ISP session to change the CKSEL fuses back to something more sensible. Perhaps the
most sensible choice (at least initially) is to put the fuses back to exactly the way they were when the chip first arrived. If you take
any AVR datasheet and go to the chapter on "Memory Programming" there is a subsection "Fuse bits" which shows each of the fuse
bytes and what their default value is.
One key thing to note is that ISP must always run at less than 1/4 of the clock frequency of the AVR. So if you apply a 1MHz clock
signal to the XTAL1 pin then the ISP programmer must be set to run at 250kHz or less.
Possible source for such a clock signal (in no particular order) are:
1) an STK500. This has an on-board clock circuit. In AVR Studio, when you connect to the STK500, you can program this clock to
some division of 3.6864MHz
2) an STK600 has a very similar clock circuit though its upper frequency limit is higher than the STK500
3) an NE555 can easily be wired up with a handful of components to generate about 1MHz
4) another AVR can be used if you load a program such as:
#include

int main(void) {

DDRB = 0xFF;

while(1) {

PORTB ^= 0xFF;

this will toggle all the pins on PORTB as fast as possible (OK, modern AVR have a better mechanism where you write to PINB - but
I'll ignore that for the time being). Anyone of those PORTB pins (together with a common GND) can be connected to the AVR that
needs to be recovered.
5) "modern" AVRs have both a fuse and a pin called CLKOUT. By activating the CLKOUT fuse (be careful this time!) the CLKOUT pin
will produce full-swing signal at the CPU's clock frequency so even a brand new chip out of the packet can produce 1MHz this way
simply by activating (setting to 0) one fuse bit and applying power.
6) Use a frequency generator set to square wave and something around the 1MHz mark (could be faster if you like)
7)
If it's just a CKSEL "accident" this should have allowed you to fix the situation.
Another potential clock problem is where you attach a crystal (with caps), set the correct CKSEL fuses and it still will not oscillate this may be caused by not setting the CKOPT fuse (if the AVR has this) or selecting "Full swing" when the crystal is 8MHz or more.

This mode of operation uses more power (which is why it's not selected by default) but is required to get higher frequency crystals
to resonate correctly. If the AVR is in this situation the foregoing technique should also recover it.
Now some chips (mainly the lower pin count ones) have some more "dangerous" fuses that can make it seriously more difficult to
recover.
The chips that can be debugged with "debugWire" have a fuse called DWEN which is mutually exclusive with the SPIEN fuse (the
one that allows ISP to operate). If DWEN is set then the _RESET pin on the chip can no longer be used to invoke ISP and can only
be used for debugWire. When a chip is in this state you need a device that can do debugWire (Dragon, JTAGICEmkII, AVR One!) in
order to recover - you need to start debugging using debugWire then (with all the ISP wires attached) use the bottom entry on the
debug menu in AVR Studio 4 where there is an option to disable debugWire mode and this will reinstate ISP mode. If you don't have
a suitable device either find a friend who does or accept that the $2-$3 that the chip cost is less than the $50 that a Dragon will
cost and write this off to experience (it's a pretty fair bet you won't make this mistake again next time you program fuses!).
Perhaps the most insidious of all the fuses is the one found on low pin count AVRs called RSTDISBL. Because these AVRs have so
few pins they can sacrifice the use of the _RESET pin to be used (usually) as another GPIO pin instead. The problem is that ISP
works by holding the chip in reset and it does this by pulling the _RESET pin low. If that pin has now been disconnected from the
internal _RESET signal in favour of using it as an I/O then you simply cannot start ISP ever again in order to recover the situation.
If it is RSTDISBL that has been set then there IS a way back but for this you are going to need a device that can do High Voltage
programming. That basically means a Dragon, an STK500 or an STK600. For the very low pin count AVRs these can do HV Serial
Programming, while for the larger ones HV Parallel Programming is used. HVSP isn't TOO bad as it doesn't use many more pins than
ISP, but HVPP is a real problem as it uses the best part of 20 pins on the AVR. What's more both HVSP and HVPP actually work by
applying +12 Volts to the _RESET pin of the chip. Most circuits that the AVR has been designed into will not tolerate having 12V
applied in this way and could be damaged and if 20 pins are involved (often 20 out of 28 ) then it's very unlikely that the
surrounding circuitry has been designed to allow the intrusion of an HVPP programmer. So if you have set RSTDISBL and the chip is
not socketed so it can be lifted and placed in an HV programmer such as STK500/STK600 or even the small prototype area of a
Dragon then accept the fact that your $2-$3 chip is lost. Desolder it from the board and write this off to experience - you'll be more
careful programming fuses next time! ;-)
BTW, when using AVR Studio (4) as a programming tool it's very difficult to have a "fuse accident" in the first place. Other
programming tools make it less obvious what's actually being chosen so you may want to use this site:
http://www.engbedded.com/fusecalc/
which mimics the interface of AVR Studio to verify that you are selecting the right values. Note that fuses are ACTIVE LOW which
means you enable them when the bit is 0 and disable when the bit is 1. Rather confusingly some programming software (PonyProg)
even lets you switch whether a tick means "enabled" or "disabled". So be very cautious next time you set fuses. Measure twice, cut
once as the old saying goes and when using ISP software to changes fuses always do a read first, determine only those bits that
need to be changed, make that change then write back.
[this is just a "prototype" article - I welcome comments and feedback for improvements]