AVR died? signature read 0xFFFFFF

[shoujin]

i just finished building this project some time ago and i tried it to program a ATtiny2313. at first it worked without any problem at all so i continue to use it to reread and verify the program from that chip (the one which i just burn) but unexpectly avr dude showed an error

intialization failed rc=-1

so i tried to lower the sck speed

first i tried to lower it to with parameter -B 32 and the error still appeared, so i decide to use -B 250 and i still got the same error. kind of courious about what happen to the chip i use command

>avrdude -c usbtiny -p t2313 -B 250 -F

and it showed an unknown device signature (0xFFFFFF). i thought the chip might be dead so i replace it with other tiny2313 chip. However i got the same problem at first it can be read and writen but whenever i reread it or rewrite it for the second or third time it always showed the same error. So i replace the chip and tried to program it again, this time i got no error but when i reread the chip something weird occured everytime i read the signature it always changed (the msb never changed though, ex: 0x91BC0!, 0x91FC00, etc).

if someone know why this happen and know how to fix this please tell me.

oh and some information i use avrdude v5.5 relase at JUN-10-2008 and usbtiny driver v1.2, oh and i use it on vista 32 bit

[adafruit]

sounds like a loose connection or bad power

[shoujin]

should i give it external power?

[zootboy]

I'd try an external, regulated power source on both the target chip and the USBtiny. I would also check for any loose or shorted wires, especially on the USBtiny.

[viulian]

I'm also having some inconsistency issues with avrdude:

Code: Select all

c:\WinAVR\projects\pwm>avrdude -c usbtiny -p 2313 -U flash:w:pwmrvk.hex:i -F

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0xffffff
avrdude: Yikes!  Invalid device signature.
avrdude: Expected signature for AT90S2313 is 1E 91 01
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed

         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "pwmrvk.hex"
avrdude: writing flash (296 bytes):

Writing | ################################################## | 100% 4.66s

avrdude: 296 bytes of flash written
avrdude: verifying flash memory against pwmrvk.hex:
avrdude: load data flash data from input file pwmrvk.hex:
avrdude: input file pwmrvk.hex contains 296 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 1.19s

avrdude: verifying ...
avrdude: 296 bytes of flash verified

avrdude done.  Thank you.

As you can see, signature is 0xFFFFFF, however, the AT90S2313's flash can be written successfully (and it works, checked the functionality).

I bricked two AT90s1200 after a write with USBTinyISP connected to my laptop's USB (on desktop the chips worked perfect, the 1200s were both read / written a lot of times as well as the 2313). After running USBTinyISP from laptop and a first write done, strangely, the 2313's signature cannot be read (0xffffff) but I can write OK - also - the 1200 return 0xffffff for signature, but can't even be written to. The 2313 (paste above) is the only one I can still program if I use the -F argument to avrdude. Somehow, just the signature is missing.

So.. I think avrdude / usbtinyisp firmware / atmel uC itself (or a combination of these) does some weird things when the circuit is a bit underpowered. Wrong bits / commands might be sent to the uC being programmed / or are badly interpreted by the receiving uC which then remains in a permanent state.
As said, a month or so the programmer worked perfect on the desktop with those uC above. After moving to the laptop, they started showing weird behavior after the first write.
If I move back to the desktop, good uCs are read / written properly, however, these ones which got at least 1 write on laptop do not recover.

My USBTinyISP is the variant which is low powered to 3.6V using to normal diodes hooked up in series after USB 5V pin, to give the programming Tiny2313 the 3.6V (I just ordered some 3V6 zener diodes for USB data pins only and intending to redo USBTinyISP).
I think I tried to program those uC (on laptop) having them also powered from 3.6V (so both the programming uC as well as the programmed uC were low powered). Maybe some kind of race condition ? I don't know. After feeding 5V to the programmed uC, results started to be consistent ( I mean I can write OK and read the signature 0xFFFFFF on the AT90s2313 I'm trying to program). Having it at VCC 3.6V produces even weirder results: sometimes the signature is read as 0x000102, sometimes I get errors when writing, etc.

I'm a bit confused and do not fully understand what goes on on Laptop and why those uC got crippled.

[adafruit]

the 2313 & 1200 are not really supported anymore, and you cant buy them so id suggest upgrading to the attiny2313 which certainly works just fine

[viulian]

Thank you for your answer, I guess you are right. Now that you said they are unsupported, I searched the net and indeed, there are clues that for 1200 the timings have to be different, and you have to fiddle with the -i argument of avrdude to get it work. However, I could not find a correct setting (and I also tried with the other parameters, -s or -b I don't remember exactly right now).

About the 2313 signature, I've just got my hands on a second hand computer with a LPT port. I'm using an 5 years old LPT programmer I also buit, which works with these older 1200/2313. The 1200 are OK, signature is read, etc.
The 2313 I broken, the sp12 also can't read it's signature, but can write it properly if the device check is forced:

Code: Select all

C:\atmel\SP12v2_1.1>sp12 -is2313 -wpf ..\WinAVR\projects\ledb\ledb.hex
SP12 version 2.1.1 performing init...
Path to _sp12rc and _sp12dev: Local directory
Running in SP12 cable/dongle compatible mode.
Enabling AVR serial reading/programming...
Device code check OVERRULED! Assuming an AT90S2313

Performing chip erase...
Writing content of ..\WinAVR\projects\ledb\ledb.hex into program area.
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
..\WinAVR\projects\ledb\ledb.hex written and verified.
write retries: 0
Writing 0000 (0, B00000000) to the parallel port data bits.
Sp12 was active for 1.23 seconds.

Just ordered a couple of tiny2313

[viulian]

Indeed, it works with ATTiny2313

Thank you!