avrdude: verification error, first mismatch at byte 0x0002

27 Aug 2021 - tsp
Last update 27 Aug 2021
Reading time 3 mins

TL;DR: Check if you’ve got the -D flag set that prevents full chip flash erase and if try flashing without to remove any garbage data.

So there you go - having written your new firmware for an Atmel ATMega and you’re going to flash it like a million times before. But nothing seems to work. You execute your usual avrdude command or use your Arduino IDE to upload your code - but it seems that - after writing correctly - verification fails and even though writing seems to have been successful your firmware doesn’t execute correctly.

To be clear this blog entry is about a specific error that sometimes happens - especially when using pre-built build scripts that try to reduce stress on your microcontroller or when using IDEs that try the same. Usually the problem is pretty simply:

You’ve configured the wrong programmer type (most of the time this should already fail at synchronization or identification step)
There is noise on your serial line. Keep the serial line as short as possible. If the cable gets longer use shielded cable (note that I usually use up to 2m of cables without any shielding - you might get away with even longer cabled with reduced BAUD rate)
Your serial line is unstable - check the cabling, reconnect everything, change wires.
Your power supply is noisy
Your microcontroller is supplied not enough current. Writing the flash memory is a task that draws a little bit more power (of course inside the specs of the controller)
Your microcontroller is damaged. This is of course possible - but usually unlikely and especially unlikely to produce this failure except you’ve written a zillion of times. Yes, the flash has a limited lifetime in terms of erasing and writing but it’s unlikely one would encounter this in the first few years …

But if the error always occurs at address 0x0002 the reason might be different. Most IDEs and many build scripts try to prevent a full flash erase whenever they program your device - especially when you’re using a bootloader to flash via a serial port because that would also destroy the bootloader. Thus avrdude tries to flash one page at a time only deleting pages that are written. And there the problem might arise: Having some strange data lingering around in your flash without having an hex file that writes to the same destination. In this case the verification step might read just some garbage.

Usually you’re programming your device using a command line like

avrdude -v -p atmega328p -c avrisp -P /dev/ttyU0 -b 57600 -D -U flash:w:example.hex:i

The flags are pretty self explanatory (be verbose, flashing for an ATMega328p, using the avrisp method via the /dev/ttyU0 port with a BAUD rate of 57600 bits per second).

The -U statement tells the flash program what to do - in this case writing (w) into flash memory, reading from the example.hex file in Intel Hex (i) format. A major problem that might occur that is able to trigger an verification error is the -D flag. This flag instructs avrdude to suppress the full chip flash erase that it would normally perform and only perform a page wise flash for every page written.

The solution is pretty simple: Remove that flag (in case you’re using an IDE like the Arduino IDE enable verbose output for the upload process, copy the whole command line into your shell and remove the flag. It should work from this moment on again as usual)