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

Last post
34 posts / 0 new
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

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

Once again I'll say it. We need a sandbox for tutorials. When it's whipped into shape, it, minus the irrelevant post like this one can be moved to the tutorial forum.

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

Rick,

What John and I have been toying with is the idea of allowing a tutorial to be posted - maybe a discussion for a month or two until it "solidifies" then locking the thread to protect against "noise" and that process may even involve the removal of the change/fix comments from that first month.

Cliff

 

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

Good suggestion.

Ross McKenzie ValuSoft Melbourne Australia

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

Is there a way that an ISP programmer can tell whether an external clock source is connected, so that it could issue dire warnings before setting the "external crystal" or "external oscillator" fuses? Assume that I'm willing to burn a short test program if that will help.

For instance, assume that I have something called OptiLoader, designed to load a new bootloader onto ATmega8/168/328 for clueless but cheap Arduino users. I can read the signature and determine which chip is there; I can read the fuses - if they are already set for a 16MHz crystal, that's great; I can probably assume that there really is one. But if they say that I am using the 8MHz internal oscillator with the divisor (factory default), I'd like to be able to tell the difference between "this is a brand new chip in a circuit with a 16MHz crystal" and "this is brand new chip in a breadboard that someone wants to make run without a crystal." Or at least I can avoid "lock out"...

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

westfw, well this article is really about when a non-existent clock has been selected but in your case if ISP can read the signature then surely the CKSEL and possibly CKDIV8 fuses can be read to determine which clock source is active (it obviously IS active otherwise you couldn't read the signature).

 

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

A clock can be made with a NOT, NOR, NAND gate feeding its output via a resistor back to the input that has a capacitor to ground.

Building an astable multivibrator with 2 transistors, 4 resistors and 2 capacitors is also not hard, but I don't know if the edges are steep enough.

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

It'd be great if you could post a schematic of that.

 

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

Multivibrator from http://en.wikipedia.org/wiki/Multivibrator

Oscillator and uC ground (negative supply) must be connected. For the multivibrator the clock output would be taken from the collector (top leg) of one of the transistors.

Any general purpose / small signal amplifier NPN transistor such as BC546 should be ok.

R1=R4=1K
R2=R3=15K (=R)

C1=C2 (=C): the smaller the higher the frequency. Maybe 1 nF is suitable.

f=0.721/(R*C)

So with R=15K and C=1nF that would be about 48kHz.

R2/3 may need to be bigger than R1/4. So if you scale each by 1/10 you should get 480 kHz.

---------------------------------

The circuits with the NOT, NAND and NOR gates require Schmitt trigger inputs, indicated by the hysteresis symbol in the gate symbol. The schematics are only visible when you are logged in.

Probably best are some CMOS types (e.g. 74HC14). You can search digikey for suitable ICs (category "Logic - Gates and Inverters"). They don't have to be very fast, but the rise/fall time of the clock edges should meet the uC specifications (datasheet section Electrical Characteristics/Clock Characteristics). Always put decoupling capacitors across the GND/- and VCC/VDD/+ pins of your ICs, something like 22 uF electrolytic and 100 nF ceramic as close as possible to the GND/VDD pins. This will help keep the rise/fall time short.
For more details see this thread: http://forum.allaboutcircuits.com/showthread.php?t=45583

Smaller timing resistors/capacitors (not the decoupling capacitors) increase frequency. You can put the output of the gate through another gate (as shown in the NOT oscillator circuit) to get a stronger, sharper signal. There are usually several gates in an IC anyways.

100 Ohm and 1 nF might be a good starting point. The extreme case would be no capacitor and a short circuit instead of a resistor, but that may be too fast and not yield a nice square wave.

You can verify the basic operation of your circuit by using big caps and resistors so you get an audible/visible frequency and hook up a piezo speaker or LED.

I have not used these circuits as clock before, so there's no warranty :).

Attachment(s): 

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

If all else fails there's a fuse recovery design here:

http://www.radiolocman.com/shem/schematics.html?di=65084

It uses HVPP.

Also this:

http://www.mtcnet.net/~henryvm/4AvrFuseBuster

 

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

AVR Dragon has HV_PROG 20 pin connector, which has XTAL1 output clock signal on 17. pin of it. I used it sucesfuly to make alive my atmega128.

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

Thanks clawson,

From an new-bee like me to AVRs this is a "must read".
I could not find any authoritive fixes for this problem until I came across this forum. spent a couple of days stuffing around! It is like everything that is new - once you know how, it is easy - the hardest thing is knowing where to look to find out how.
Make it a "sticky" to help dummies like me can find it easily.

Thank you :D

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

Quote:

Make it a "sticky" to help dummies like me can find it easily.

I think you'll find that every article here in Tutorial is equally valid/useful and all would warrant being "sticky" in that sense ;-)

(the evidence here tends to show that most newbies ignore anything that is sticky anyway :-()

 

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

Your probably right, The whole sit could be a sticky :D

Thanks again,
now that I have found where to look I will be more thourough in my investigations.

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

Hi Clawson, Thanks for the useful guide. You might wish to add to it that programming with a Vcc on the Tiny 13 of < than 4.5 volts can lead to problems with the reported fuse settings when using AVR studio 4 and an AVRISP2. Whilst I have successfully programmed hundreds of Tiny13s with a target board powered with 2 x AAA cells there have always been a few failures due to screwed clock fuse settings. However increasing the Vcc from an nominal 3 volts to 4.5 volts (by adding another battery) seems to have cured the and I can recover some of the chips with the screwed fuses. Hope this helps.

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

That's not real a general issue but a question chip specification. The Tiny13 datasheet says:

Quote:
ATtiny13: 0 - 10 MHz @ 2.7 - 5.5V, 0 - 20 MHz @ 4.5 - 5.5V

So I assume you were clocking the 3V powere chip above 10MHz. As such you got what the datasheet predicted. If, on the other hand, you are saying you were running at below 10MHz and this occurred then that is an issue you should take up with Atmel to either determine whether they are producing chips out of spec. or whether there is an error in the datasheet that should be amended.

 

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

Can you fill me in a bit more on using the stk500's internal clock to rescue my AVR? (I.e. what physical connections need to be made between programmer and AVR? Any flags I need to change on my command line?)

I fell into this pit, setting the fuse for oscillating clock, when I should have set it for crystal. I'm using an Arduino UNO as my AVR programmer (in the Makefile, it's specified as stk500v1, so I hope that counts) for an ATtiny85 AVR. (I have another Arduino, in case one is needed for the clock and one needed for the programmer.)

My Makefile specified (when I bricked my ATtiny85):

F_CPU = 16000000L
AVRDUDE_PROGRAMMER = stk500v1
AVRDUDE_BITS_PER_SEC = -b 19200 // already a factor of 3.6864MHz, right?
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Can you fill me in a bit more on using the stk500's internal clock to rescue my AVR? (I.e. what physical connections need to be made between programmer and AVR? Any flags I need to change on my command line?)

STK500 manual is online here:

http://www.atmel.no/webdoc/stk500/stk500.section_vmj_jwk_yb.html#stk500.section_znj_jwk_yb

 

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

http://www.robotroom.com/Atmel-ATtiny-STK500-Programming-4.html

I found the above link helpful in visualizing the STK-500 jumper settings
as relates to the ATtiny devices.

It is easier to read than the STK-500 manual/help file.

High resolution graphics remove any
ambiguity in how the jumpers are implemented. Covers both the ISP and
HVSP modes and jumper settings.

Hope this is some help.

I'll believe corporations
are people when Texas executes one.

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

Thanks. Problem resolved. I found this a good starting point: http://hlt.media.mit.edu/?p=1695

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

I would like to point out that this frequently visited tutorial lacks the (important) information that communication via JTAG does not require any valid clock source.
Even when external crystal is selected and physically removed, or when invalid clock setting is made - JTAG still works fine. The chip can be read, programmed or erased then (as long as JTAGEN is programmed).
What is more, also NRESET is of no use with JTAG as for JTAG dongle this pin acts only as input (although some dongles can assert it on demand).
I do not own a JTAGed RSTDISBL chip (like m169pa) but if anyone has such chip along with HVPP standing by, I encourage to try playing with it via JTAG and report.
Remember: "No RSTDISBL - no fun."

No RSTDISBL, no fun!

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

Guys,

perhaps anyone could offer some assistance with the problem im having ?

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=1050827#1050827

i have access to AVR tools (USBASP and so on) and JTAGE Ice.

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

I know this is naughty but...

... bump (makes it easier for me to find the thread ;-))

 

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

I have probably programmed a few thousand new AVR's but I always drop my ISP speed to 125khz, program the crystal speed and other fuses, then go back to 2mhz ISP.
Then yesterday I reminded myself why I do this.
I forgot to drop the ISP speed and programmed the fuses.
I can only conclude the AVR accepts some values under high error rate and sets things not intended. The verification will then fail and ISP no longer function.
I used, as this thread suggests, a 1mhz signal from a signal generator at logic level and read the fuses. CKSEL was not what I set and DIV8 was also set.
Set them correctly and the AVR is recovered.