AVR Atmega32 flash verification error

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.