Avr signature doesn’t match, flash address 0x0000 wrong

avrflashmicrocontroller

I'm new to electronics.

I've bought an ATmega32 (a link to docs) and I'm trying to light up a single LED. I have managed to do it a few times, but then I tried to change the hookup wires to a single 10 pin wire and after a few failures, I went back to wires.

The problem is, when I try to program the device, it gives me a warning:

WARNING: FLASH byte address 0x0000 is 0x00 (should be 0x0C).. FAILED!

When I read the signature of the device straight after plugging it in, it says it's

0x1E 0x95 0x02

and it says it matches the device.
Then when I try to erase it (or program it), I got the mentioned warning. Also, after doing this, when I read the signature of the device, it reads it from the device as

0x00 0x01 0x02

There's also a warning that 'signature does not match selected device'.
I can erase the device and it says that erasing device was OK.

I'm not sure if that's relevant or not, but I've also realised that fuse bits (low to high) are at the beginning 0xE1 0x99 and later 0x04 0x04 and after erasing it changes the

SUT_CKSEL Int. RC Osc. 1 MHz; Start-up time: 6 CK + 64 ms; default value

to

SUT_CKSEL Int. RC Osc. 8 MHz; Start-up time: 6 CK + 0 ms

(it also changes some other fields there as well, e.g. brown-out detection from VCC=2.7V to 4.0V)

I'm using AVR Studio 4.18.716, and a JTAG ICE programmer.

Is there anyway I could fix this or have I killed it?

Best Answer

Most likely you are running the programmer at too high of a bit rate. The bitrate can be set on the command line with the -B N flag, where N is the period of the programmer SCK signal in microseconds. Try something high like -B 100 and see if you get more consistent results. The following link seems to show how you would set this up in AVR Studio (v4): Atmel STK500 Programming.

Related Solutions

Electronic – AVR Atmega32 flash verification error

Have you been able to verify at all that the device is responding at any level? You say you programmed the fuse bits, but have you been able to verify that they were actually changed?

According to the data sheet:

The SPI Serial Programming instructions will not work if the communication is
out of synchronization. When in sync. the second byte ($53), will echo back
when issuing the third byte of the Programming Enable instruction. Whether
the echo is correct or not, all four bytes of the instruction must be
transmitted. If the $53 did not echo back, give RESET a positive pulse and
issue a new Programming Enable command.

Perhaps you could see if you can test this, either with an option to/modification of avrdude, or even just looking with a scope to see if the miso line is wiggling at all?

I'd think the question has aged enough that if it's still an issue, ordering any older chips from the atmega8/16/32 family to test the programmer would be worthwhile.

The atmel literature seems to imply that the change are primarily fab process related, so it's possible that the new device might be more noise sensitive in some respects.

Electronic – Watchdog Signature in Flash memory or RAM

Usage of memory storage signatures to determine if a watch dog timer is what has caused your last reset is a scheme that should be avoided at all costs. That scheme is fraught with problems and does not provide a fool proof scheme.

Here are some key factors to consider here that lead to this being a problematic approach. (There are others as well so analyze carefully).

1) Signatures stored into RAM may or may not be legitimate after a power cycle reset becasue RAM can maintain its content for some period of time after a power cycle.

2) A watch dog reset is likely caused by a spurious error in the hardware electronics some place. How can you be certain that this has not compromised the storage of the signatures?

3) The storage of signatures into FLASH or other non-volatile memory is problematic due to the fact that the watch dog timeout / reset could occur during the time that such signatures are being stored.

It is far superior to setup your system hardware with logic that captures the "reset reason" into special flop-flops or register bits that the software can poll in its startup sequence to determine if the restart was due to a watch dog timeout. If your system processor does not have this built right into the chip then consider substituting another processor that does include this capability. In cases where the watch dog is implemented outside the controller look into adding a simple external circuit that can provide the "reset reason" to the processor through an I/O pin.

Related Topic