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!
Split from: Recovering from a "locked out" AVR
How can I recover my Atmegas?
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.
(as far as I know I did it correctly
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
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.
and it was 0xff.
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.