Suddenly cannot flash ATmega328P due to verification failure

atmegaavrdude

For a couple of years I have been flashing some boards I designed that use an ATmega328P using a USBtinyISP and avrdude. I have three identical boards that have been programmed successfully dozens of times. Suddenly I cannot program ANY of them. In every case, avrdude gives me a verification error. For any given board, it's the same address, but each board fails at a different address (0x02df, 0x0a97, and 0x043f). After the failure, two of the boards appear to be working (LEDs react appropriately) but I would not trust them. Interestingly, a fourth board, used for development, occasionally (rarely) flashes successfully. FWIW, the boards are connected to the USBtinyISP via pogo pins. But this connector has been working for a couple of years. I can see in my scroll history multiple successful flashes just two days ago!

What could possibly be causing this complete failure? What can I try? I'm at my wits end.

Best Answer

The problem is gone and I wish I could say exactly why. In an act of sheer desperation I did a make clean and then make in the main firmware directory (there are libraries in a couple of other directories that I did not touch). I then flashed a board that had not worked and it passed verification! So I did another board. Passed. And another. Passed. And another. 100% success. No failures at all

I cannot explain why just rebuilding the flash would fix this. As far as I know, avrdude just writes the hex file, reads it back, and compares the two. If anybody has any possible explanation, I'd love to hear it.

On the other hand, there was a lunar eclipse the night before this all started...

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 – arduino – Need explanation on how to flash HEX files on ATmega32u4 via AVR109 protocol

I have been using dfu-programmer successfully on Linux (using a "bare-bone" atmega32u2/atmega32u4) from the command line. So it's very easy to integrate it in a Makefile.

A quote from that web site:

dfu-programmer-0.6.2.tar.gz contains the source tree for this project. Download this to build and install on a Linux/Unix/Mac system.

So you should be able to build it on a Mac. Or you can have a look in the source code.

Best Answer

Related Solutions

Electronic – AVR Atmega32 flash verification error

Electronic – arduino – Need explanation on how to flash HEX files on ATmega32u4 via AVR109 protocol

Related Topic