Hi there,

I have a problem I ruined my fuse bits in my AVR Atmega644 device. I know it's MY FAULT. I guess I am not the only one who screwd up the fuse bits and make the device unusable. The problem is the following: if you screw up the fuse for the
Atmega, the device will use a different clock source. In my case it's the low frequency internal oscillator, and it runs around 128kHz.
Now, the SPI clock that the programmer uses is definitely too much from this point and the software will not recognize the device any more.
I quick fix would be if ponyprog could slow down the SPI communication extremely.

/ BTW what a stupid design that a device uses user-predefined clock sources under the programming cycle. It should be a fixed frequency. I think it's a big mistake of Atmel./

Now I have two screwd Atmega644. If there was a ponyprog where the SPI
frequency is very low (2-5 kHz), then I would try it and see if this solves the problem. /Authors, please help. Or anyone who can compile the source./
If this works, it would be a big help for others, too. It's a really annoying issue.

(The SLOW/VERYSLOW configuration options in the INI file did not help eighter.)
Can anyone help?

BTW, it's a great software. I really mean it.

Jozsef

yes, i have the same problem. i switched attiny13 to 128khz and maybe left div8 fuse, so it makes 16khz clock although i wanted such low clock, but now i cannot write any software to device.

I used AVRDUDE and worked! In the package WinAVR there is a command line programmer, which can decrease the SPI clock.
I used this:
avrdude -p m644 -c stk200 -t -i 1000 -F
(the magic switch is the -i, which sets up the SPI period)

Then it enters terminal mode, so you have to use some commands, but there is a
documentation for the avrdude so you can repair your fuse in a couple of minutes.

So this is a feature that definitely misses from ponyprog. Hope it will be
there soon...

jozsef

i`m using such programmer.
http://www.elektronika.lt/_sys/storage/2004/05/06/avr_prog.gif

enter into avrdude such command and got the result:
>D:\WinAVR\bin\avrdude.exe -P com1 -c ponyser -p t13 -i 1000 -t

avrdude.exe: AVR device not responding
avrdude.exe: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.


avrdude.exe done. Thank you.

not too much lucky though. so looked to avrdude.conf about ponyser and it seemed to be ok, even tried to change pin7 to pin6, but got the same result.

any sugestions?

edit:
i think i cannot use avrdude.exe with my programmer. maybe will try to make a one based on LPT port and try again some day.



Edited 1 time(s). Last edit at 10/07/2007 06:31PM by R2D2.

I use this programmer, which compatible with stk200 I guess.
Should not be too hard to build

http://www.scienceprog.com/simplest-128-atmega-programmer/

works both with ponyprog and avrdude


jozsef

pity, but it didnot work either. will try on my friends usb programmer, maybe with little luck everything will be fine

Why don't you try to modify the delay value (-i switch)
If you're sure the contorller gets clock then it should work with a huge
delay. I'd go higher with small steps like 1000 1100 1200 ...

jozsef

ofcourse i tried with higher delay just in a bit greater values 1000 2000 10000 100000 but because thier could be a problem with contacts (i put simple wires inside port) so gave it up. i tried to unjust the clock on usb programmer with avr studio, but no luck. now i have the socket fot LPT port and can be sure of the contacts. and get to work

is the programmer just 4 resistors? because now i built one, but with no luck again trying many values as i can.

i think i need a high voltage programmer, which sets +12 on reset pin.

I don't think the problem is the programmer. Are you 100% sure that your chip is clocked? The problem is that the SPI bus needs the clock source anyways. It's jush a stupid thing, but we have to understand that using either the SPI or JTAG bus as a programming source is not the right way. For a real programming I guess the paralell interface is the right one. That one does not need the clock source on the XTAL inputs. This is my problem too, I have another atmega644 which is clocked from low freq. crystal and I do not have a 32k crystal, so the SPI programming method won't work. I think I'll have to build the paralell programmer sometime later.

joco

i made a clock source from attiny2313. but this didnt help. so i bought a new chip and thats it. maybe i`ll try sometime.

case postponed

I have a similar problem... I'm definitely willing to put the blame on my (drunk) self.
I built a Pony Prog STK200 programmer the other day, and quickly tested it by reading the fuse bits of my ATmega32, and it seemed to read alright.
Then I went out and had a bit to drink. When I came home for some dumb reason I decided to test the programmer further by writing fuse bits.
From my vague memory, I cleared the "CKOPT" bit, and programmed it. It seemed to work, but when I clicked read, it errored.
When I woke up, I noticed that the device was set to ATmega128 (one of my other devices).

If I tried to write to the ATmega32 with the device set as ATmega128, would it ignore the fact that the device is different, or should it detect a different device and abort programming?
Also, would this kill the device?

so i made a stk200 dongle (or lpt programmer with 74HC244). bus it did not work either. it reads the working tiny13 very well, but does not recognise the chip, which i ruined oh, very well, will be a lesson for future i think

EDIT: the last chance i think is High voltage programmer. but this will not happen soon.



Edited 1 time(s). Last edit at 10/23/2007 12:32AM by R2D2.

i have the same problem while programming fuse bits on AVR controllers...

The controller gets locked on changing the CKOPT fuse bit. I am college student and have access to the Atmel AVR ISP mkII programmer here in the College Hobby Club Lab. Using the AVRISP I was able to unlock the controller and set the fuse bits back to the default value. The controller then seems to work properly. In my view, it is a problem of the CKOPT fuse bit. According to the datasheet, the controller switches the mode of operation of the differential amplifier for clocking purpose. I wonder whether there is some hardware problem in the programmer design as the AVRISP was able to read the same controller and it uses the same pins for the purpose. And I am sure it wasnt a fault of the circuit board, the soldering, wires, connectors or alcohol either {] cause I tested the case on atleast 3 different working boards and controllers.

Do let us know if someone finds a solution to this problem.

And as far as the clocking is concerned, all this while I thought the SCK pin was used for supplying serial clocking to the controller. Let me know if I was wrong...