0

I have a 2560 that I've been working with for a while (over a year for sure), programming it with an avrisp mk2. No issue this whole time, then suddenly, a couple of days ago it starts failing with

avrdude: verification error, first mismatch at byte 0x0002
         0x01 != 0x95
avrdude: verification error; content mismatch

And very obviously not flashing (there's logic that blinks the LED on boot, and the LED isn't blinking anymore).

The first time this happened, the board appeared completely dead - the programmer wouldn't recognize it, and refused to flash it. After a few days and magic it started recognizing it again, and going through the motions of flashing my firmware, but the verification error persists. The location of the error hasn't changed, nor has the two values (0x01 vs 0x95).

Any ideas what this could be?

Improve this question
5
  • I have seen this myself. It turned out that coms were a little distorted. If you have access to one, use an oscilloscope to view the waveforms of the 4 ISP pins.
    – sa_leinad
    Dec 18, 2018 at 15:22
  • Similar to: arduino.stackexchange.com/q/44965/19409 arduino.stackexchange.com/q/30946/19409 arduino.stackexchange.com/q/52798/19409
    – sa_leinad
    Dec 18, 2018 at 15:27
  • @sa_leinad why would the coms get distorted after such a long time? i'll scope it tonight when i can.
    – kolosy
    Dec 18, 2018 at 16:19
  • 1
    Track corrosion, static damage, dry joint just to name a few.
    – sa_leinad
    Dec 19, 2018 at 1:41
  • I am running into the same program with Arduino Uno when using avrdude from the command line. Burning the bootloader before uploading my code similarly solves the problem.
    – Kavka
    Dec 8, 2019 at 23:21

2 Answers 2

Reset to default
2

Still don't know why, but now have a fix. Re-running the 'Burn bootloader' command from Arduino allowed me to then burn my firmware. Not sure if the issue is with fuses somehow being changed, or what, but this seems to have fixed the issue.

One more fun fact - I tried the same thing on a brand new Mega - same effect. First trying to burn my firmware resulted in a verification error (at a slightly different address), then burned bootloader and re-burned my firmware successfully. Wondering if an update to boards.txt or avrdude came through and changed something.

Improve this answer
1
  • Had the same problem. Did the same thing: burn bootloader then burn my sketch. It worked.
    – Wu Yongzheng
    Oct 18, 2020 at 3:22
1

TLDR: Make sure that -D flag is not used when calling avrdude to upload your app using the ISP programmer.

After burning the bootloader on a bare ATmega328p chip using the Arduino IDE and an Arduino Uno as ISP, I am running into the same problem that the OP mentioned with this message:

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0094
         0x68 != 0x6a
avrdude: verification error; content mismatch

Right after burning the bootloader, I can upload an application using this avrdude command (yours would vary slightly due to port name, etc.):

avrdude -C/etc/avrdude.conf -v -patmega328p -cstk500v1 -b19200 -P/dev/ttyACM0 -D -Uflash:w:main.hex:i

However, if I change the application code, recompile, and rerun the same avrdude code again, then I get the verification error mentioned by the OP.

In my case, I have confirmed that the -D flag is the problem. In fact, if I remove the -D flag in the avrdude command above, then I can change, compile, and upload my code as many times as I want.

Note that this is different when using the Arduino IDE to program an Arduino Uno directly (using serial communication through the bootloader), where the -D flag is used

avrdude -C/etc/avrdude.conf -v -patmega328p -carduino -P/dev/ttyACM0 -b115200 -D -Uflash:w:main.hex:i

since you wouldn't want to erase the bootloader on the Arduino Uno. Somehow using the -D flag is OK in that case.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.