[TUT][SOFT] Recovering from a "locked out" AVR

34 posts / 0 new
Last post
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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 mis-set. 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]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So should the thread be now locked as discussed elsewhere before we get 2 million posts and we won't be able to see the forest for the trees? :-)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What did I miss while I was away?

Anyway, I'm still open for suggestions/changes/improvements - but this thread should not be used for anything else - such as discussing specific instances of "lockout"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
POTB ^= 0xFF; 

I think you made a typo there.
should be PORTB

[thanks - corrected now - it's this new PC - where the keyboard cannot seem to cope with fast typing PORT :-(]

1)Datasheet and application notes checked?
2)tutorial forum
3)Newbie start here

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another one is that a large number of AVR's has a CLK/8 fuse.
when this fuse is set the actual CPU frequency is 1/8th of the frequency applied to the XTAL1 pin.

So when one is not sure if this fuse is set or not then also take this into account.

example when applying 8MHz to the XTAl1 pin, the actual core frequency is only 1MHz as you need to be below 1/4th of that the maximum programming speed is 250KHz. Keeping in mind that the actual frequency could be below that so better be safe and take the programming speed that is lower then the 250KHz ( the actual choice depends on the programmer used).

regards

[good point - though I mentioned 250kHz I forgot to emphasise that this should be tried first if things aren't "talking" - OTOH a "lockout" tends to suggest a chip that was working but has lost contact after a "fuse accident" so that kind of implies they started out with ISP using working settings?]

1)Datasheet and application notes checked?
2)tutorial forum
3)Newbie start here

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nice tutorial Cliff,
It would be nice, if you could throw some light on number of options that are displayed in dropdown list while setting the SUT_CKSEL fuse from AVR studio in the form ; Start-up time: CK + ms
for instance;Int. RC Osc. 1 MHz; Start-up time: 6 CK + 64 ms
In mentioned above what does the Start-up time indicate? How to determine which option to select?

P.S. If this is irrelevant please delete the post[/b]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kulu,

I don't think I'll go there as this is specifically how to recover from "lockout" though I guess if you have a crystal with a stupidly low SUT time that could be an issue so I may mention that.

Most AVR datasheet have a good section on clock options that explains the options in such a droplist.

Cliff

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And, to add to Cliff's latest post: Unless you have compelling reasons to do otherwise, stay with the longest possible SUT. It's there for dealing e.g. with power supplies that take a (relatively) long time to start up.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

It's there for dealing e.g. with power supplies that take a (relatively) long time to start up

I thought it was for crystals that took a long time to start resonating?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
this thread should not be used for anything else
Neither should the other tutorial threads.. :-) oh did you break your rule above? :wink:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Pages