Split from: Recovering from a "locked out" AVR

Log in or register to post comments
Go To Last Post
6 posts / 0 new
Author
Message
Aranha
Aranha's picture
Level: Rookie
Joined: Sun. Aug 31, 2014
Posts: 29 View posts
#1
Posted by Aranha: Fri. Oct 20, 2017 - 01:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey everybody, I've got a problem. I just locked my 3 uCs: 2x Atmega8L and Atmega32A. I set all of them to use internal oscillator, for example I used following command for Atmega32A: avrdude -p m32 -c usbasp -U lfuse:w:0xe1:m - the value of 0xe1 I got from http://www.engbedded.com/fusecalc/ . I'm using a USBASP for programming and since I've set unfortunate internal oscillator I can't get any response from the uC... How can I recover my Atmegas? :( Any help will be appreciated!

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Last Edited: Sat. Oct 21, 2017 - 11:07 AM
Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 102300 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. Oct 20, 2017 - 01:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Aranha wrote:
How can I recover my Atmegas?
Have you actually READ this thread?? The whole point of me spending some time writing post #1 here was to explain how to recover. Did I waste my time creating this thread then?

Top
Aranha
Aranha's picture
Level: Rookie
Joined: Sun. Aug 31, 2014
Posts: 29 View posts
Posted by Aranha: Fri. Oct 20, 2017 - 01:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, Sir, you did not waste your time, it's a great tutorial! I may not have read all the words in the thread but I jumped from problem to problem and from what I can see people actually have the opposite problem - they set the oscillator to external and can't get their uCs work. I, on the other hand, set the internal oscillator (as far as I know I did it correctly - I showed the command) and then my atmegas stopped working. So I cannot drive my uCs with external oscillators to make them run because these atmegas are set to not care about any external oscillator. If my case was solved somewhere here, I'm sorry, I just can't find it.

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 102300 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. Oct 20, 2017 - 02:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Aranha wrote:
(as far as I know I did it correctly
But I don't think it worked as you expected. The chances are you have set it to something wrong. If you are lucky RSTDISBL has not been changed in which case just applying a clock signal to XTAL1 (as per tutorial) will solve the issue. Have you even tried?

 

BTW 0xE1 is the default value for lfuse for both mega8 and mega32 so assuming your operation worked as expected what were you hoping to achieve anyway? You were setting a new value that is identical to the existing default value anyway?!? If behaviour then changed clearly you did NOT set it to 0xE1

Last Edited: Fri. Oct 20, 2017 - 02:03 PM
Top
Aranha
Aranha's picture
Level: Rookie
Joined: Sun. Aug 31, 2014
Posts: 29 View posts
Posted by Aranha: Fri. Oct 20, 2017 - 02:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BTW 0xE1 is the default value for lfuse for both mega8 and mega32 so assuming your operation worked as expected what were you hoping to achieve anyway? You were setting a new value that is identical to the existing default value anyway?!? If behaviour then changed clearly you did NOT set it to 0xE1

It was not set to the default value - I remember playing with clock some time ago. Before I used the command I provided in my first comment, i checked the value of lfuse and it was 0xff. Obviously I was able to connect to the uC and program it. After the fuse change I'm not able to do anything, I get 'target doesn't answer'. Look, I still have my powershell open and I can see what command I applied and what the result was so it's not like I'm guessing or making up all of these values.

 

You also say that my command did not work as expected. Well - I did it three times on three different uCs the same way within an hour or two - all of them are unusable now. Could be a coincidence, yes, but the probability is too low for me to believe in it.

 

I haven't tried any STK*** solution because I'd rather buy a new atmega for like $2 than spend muuuuch more for a board. The external uC solution did not work and I don't have any frequency generators.

For the sake of completeness - I use USBASP programmer which I connect to a pcv AVT1452 which has a 8MHz oscillator on it. I tried programming without this AVT1452 - directly connecting ISP to uC pins on a breadboard but it didn't work as well.

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 102300 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. Oct 20, 2017 - 02:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Aranha wrote:
and it was 0xff.
But that is the setting for:

 

 

So it was already set to "Ext crystal". So do these chips already have Xtal connected across XTAL1/XTAL2 with small caps on each to Ground?

 

I can't help noticing that 0xFF might also be a result of a chip that cannot be contacted. So when you read the 0xFF did avrdude report that the signature bytes were OK? (that is 0x1E,... etc)

 

It sounds very likely that all that has happened here is that your ISP programmer is FUBAR.

 

Anyway my thread here is for a tutorial and comments arising from the text of it. Sounds like it's time to take this to another thread.

 

To encourage that I will lock this for the time being.

Top