AVR Atmega32 flash verification error

I just got an Atmega32A chip and I've been trying to program it with a usbasp for quite a few hours. I can change the fuses and write the program, but verification fails.

I'm getting this message after verification:

avrdude -c usbasp -p m32 -u -U flash:w:first.hex


verification error first mismatch at byte 0x0000

0x0c != 0x00

I'm connecting according to this diagram here:

The chip can be erased and fuses can be changed, my only problem is with the verification. The program seems to be written to memory but my LEDs aren't blinking.

Could this be a problem with my connections? Can anyone point me to a better programming schematic?

• I would like to see two things. Confirmation of a working programmer for this chip and an explanation of how you know it is connected properly and how to go about designing one. This will be getting a bounty when it hits the age that I may add one. – Kortuk Jul 26 '11 at 14:50
• Have you checked the lock bit settings? The lock bits can be set to disable writing and verifying flash. – Phillip Dixon Jul 28 '11 at 11:07
• Can you please post your current fuse settings – Toby Jaffey Jul 28 '11 at 11:14
• How many times have you written to/from the chip? There are a limited number of writes, and it's also possible that you have a defective one (if you're sure all of your programmer settings are correct and there is no bad connection). – Breakthrough Jul 29 '11 at 14:16
• How do you hook up a flash programmer for this chip and what are the lines for!? 300 rep here, Begging for someone to answer now. – Kortuk Aug 1 '11 at 4:44

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.

• Thanks for your answer. The problem was probably with my breadboard and FRC cable. The programmer and the chip are new and working perfectly now. – tecfreak Aug 3 '11 at 12:34

If you run avrdude with only the options that specify your programmer and the target device, it will confirm that it can talk to the device correctly.

avrdude -c usbasp -p m32


The output you see should confirm that your programmer is connected correctly.

The next thing I would check is your power connection. Do the programmer and the target circuit share the same power supply? If possible, power your device from the same USB hub that powers your programmer. If that solves the problem, then you will probably need to learn more about how the usbasp can be buffered.

There are too many possible reasons for your problem to cover them all, but the key to finding the solution is to start simple, and check your assumptions at every step. Eventually you will find the solution, and you will have gained good experience from finding it.

• I am picking your answer as verifying the programmer was functioning would have narrowed the problem to connections between the programmer and chip. – Kortuk Aug 3 '11 at 13:10

I feel that some information is missing. First, please paste everything avrdude returns when you run your command (i.e, does it read the device signature correctly?) Second, show us the status of your fuse bits (i.e, do you clock the device by the external crystal or internal RC osc?). Third, how do you power the microcontroller and how is the USBasp powered?

Right off the bat there is one thing you could try though: lower the ISP frequency. If you have a 4MHz clock and the CKDIV fuse programmed, the default (100 kHz) ISP freq should be safe but try lowering it to ~10 kHz by adding -B 100 to your command. I have no experience with the USBasp, if -B does not change the ISP freq you could try using the -i flag instead.

• your first paragraph should form a comment, not an answer. – Kortuk Aug 2 '11 at 11:14

You ought to be using the official Atmel 2x5 connector, which matches the one used on the USBasp.

Can you program another AVR device?

You should get get a proper AVR programmer such as the AVRISP Mk II or Dragon, you'll have fewer problems. The Dragon gives you in-circuit debugging as well as programming, which is very useful.

• So you think its most probably due to the programmer? I don't have another device to test. I just hope its not the chip malfunctioning. Is the circuit diagram above correct for programming? Also what is the function of RESET pin during programming? – tecfreak Jul 26 '11 at 3:57
• Please reply, what should I do? – tecfreak Jul 26 '11 at 12:23