Verification error, content mismatch (Arduino Uno)

[super3go]

Hey guys, I've been having with my Arduino Uno board that I ordered from Adafruit.

For the first couple of uploads, the boards worked flawlessly. I wrote a program to simulate my project's function, and everything was great. I use a Windows 7 laptop with the arduino IDE downloaded from the official site.

Today however, I tried to connect the board to the computer and upload another program I was working on. This error came up:
Error:
avrdude: verification error, first mismatch at byte 0x0000
0x0c != 0x00
avrdude: verification error; content mismatch

Believe, I've looked through Arduino's Troubleshooting Guide, and through various other topics posted on both the Arduino forums and the Adafruit forums, but nothing has worked for me. If at all possible, I'd refrain from returning the board until it is absolutely necessary.
Some facts:
-bootloader works: pin 13 flashes LED whenever I reset.
-Arduino is powered on without hitches: green light
-pressing reset and then immediately uploading program did not help
-It was literally working the other day. I put it in a box for the night, came back, and had this error.

What can I do to get my Uno back in operation?
Thank you in advance!

[adafruit]

hmm, we'd like to check this out. can you email support@adafruit with a link to this thread and request a return envelope with a new uno?

[jac]

Greetings,

I have a situation similar to the initial post. I've been using an Arduino Uno from Adafruit since December, loading and reloading an evolving program. Today it quit loading and issues the "content mismatch" error. The environment is Windows XP, Arduino IDE.

I've isolated the Uno (removed shield, extra circuits) and tried to load the Blink example but the old program is still in memory. I can see it in the serial monitor complaining that the data logger and RTC aren’t available.

Pin 13 led flashes on reset, the tx/rx leds flash when uploading, the power led is on and the 3.3 and 5.0 voltages meter ok.

Is there a way to get past this error and get the Uno back in operation?

Thanks!

Full error:
---------------
avrdude: verification error, first mismatch at byte 0x0000
0x0c != 0x62
avrdude: verification error; content mismatch

[adafruit_support_bill]

Does the board reset when you connect the USB cable or start a download? Try pressing reset as soon as the IDE displays the compiled program size.

[jac]

The LED on pin 13 flashes when plugged into the USB and then stays on. During an upload from the IDE the LED flashes prior to seeing the tx/rx LEDs flash then pin 13 LED stays on. Pressing reset as soon as the IDE displays the compiled size doesn’t seem to make a difference, the error still occurs.

[adafruit_support_bill]

Sounds like the 8U2 usb/serial is working properly, and the Atmega 138 is running the sketch OK. You might try a different USB cable and/or USB port on your computer.

[jac]

I’ve tried different USB ports on the PC with no effect and the serial output from the program that’s running on the chip reads fine in the serial monitor. After a reset, the serial monitor shows a few messages, waits for a serial input and when it gets one it prints errors that the shield is missing. So the cable seems fine but I’ll pick a new USB cable on the way home tonight and give it a try.

Everything I could find on this error pointed to flaky communications hardware, cables or USB. Is it possible I trampled the bootloader with an aberrant program or by loading a large (31K+) program? Could this be a problem in the ATmega328?

[adafruit_support_bill]

You could try re-burning the bootloader (under the "Tools" menu).

[jac]

Clicking on Tools->Burn Bootloader gives me: avrdude: usbdev_open(): did not find any USB device “usb”. Besides, don’t I need some other setup to burn the bootloader?

Things I tried last night that didn’t work:
- replaced the USB cable
- unloaded and reloaded the Arduino USB driver
- connected an external 9v power supply incase the USB wasn’t enough
- reloaded the Arduino IDE
- loaded the Arduino IDE on another PC and tried it there – same results.

Using verbose on upload shows all bytes read from the Arduino flash memory are 0x62.

Code: Select all

avrdude: reading on-chip flash data:

Reading | avrdude: Send: U [55] . [00] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: t [74] . [00] . [80] F [46]   [20]
avrdude: Recv: . [14]
avrdude: Recv: b [62] b [62] b [62] b [62] b [62] b [62] b [62] b [62] b [62] b [62] b [62] b [62] b [62] b [62] b [62] b [62] b [62] b [62] b [62] b [62] b [62] b [62] …

I’m figuring the board is the problem but there’s this mystery: avrdude is reading all 0x62 (on two different PCs) but the serial monitor is showing the correct output from the program on the chip which would indicate the serial output is ok.

Any other ideas before I buy a new board to fry?

[adafruit_support_bill]

Not sure what is up there. But the Atmega 138 would be the chief suspect. You can get a 138 with a pre-burnt bootloader here for $5.95.

[jac]

Resolution: the Arduino Uno Rev 3 described above that wouldn’t load sketches is now operational after flashing new hex files.

I first tried all the recommended procedures of changing cables, device drivers, PC, etc. I then ordered and installed a new ATmega328P from Adafruit but sketches still didn’t load. However with the new 328P the board exhibited different behavior compared to the original 328P. When attempting to load a sketch on the original 328P the TX/RX LEDs would both flash but with the new chip only the RX LED would flash, not the TX.

At this point I figured I’d try flashing the ATmega16U2 using a USBtinyISP (also from Adafruit ). After flashing, the Uno still wouldn’t load sketches but both the TX and RX would flash when attempting to load the new 328P. I then tried the new 328P in a functional Uno and it wouldn’t load sketches so I put it back in the “bad board” and flashed a new bootloader. After flashing both the 16U2 and 328P, sketches load fine. I then flashed the old 328P and it works fine too.

I had to hunt around for the correct avrdude usage so here's what I used for the ATmega16U2:

Code: Select all

avrdude -p m16u2 -c usbtiny -C c:\tools\arduino-1.0\hardware\tools\avr\etc\avrdude.conf -U flash:w:"C:\tools\arduino-1.0\hardware\arduino\firmwares\Arduino-COMBINED-dfu-usbserial-atmega16u2-Uno-rev3.hex":i -U lfuse:w:0xFF:m -U hfuse:w:0xD9:m -U efuse:w:0xF4:m -U lock:w:0x0F:m

I used the Arduino 1.0 IDE to flash the ATmega328P but the command line was:

Code: Select all

C:\tools\arduino-1.0\hardware/tools/avr/bin/avrdude -CC:\tools\arduino-1.0\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega328p -cusbtiny -Uflash:w:C:\tools\arduino-1.0\hardware\arduino\bootloaders\optiboot\optiboot_atmega328.hex:i -Ulock:w:0x0F:m

[westfw]

avrdude is reading all 0x62 (on two different PCs) but the serial monitor is showing the correct output from the program on the chip which would indicate the serial output is ok.

Huh. I wonder if that is what happens if the memory protection fuses end up set wrong?
If it happens again, try reading the whole chip (fuses, protection, flash) with your USBTINY so we can look for additional clues... It shouldn't be possible to overwrite the protection fuses in normal operation, but there have been other occasions where the bootloader and/or fuses have been mysteriously trashed (requiring a re-upload of the bootloader.)

Another thought - you aren't managing to keep a serial monitor window open while you're attempting an upload from another window, are you?

[jac]

you aren't managing to keep a serial monitor window open while you're attempting an upload from another window, are you?

I've been using the IDE and it closes the serial monitor window prior to uploading so I don't think that's the case.

try reading the whole chip (fuses, protection, flash)

I ran avrdude with a -v on the 16U2 on a good board and the "bad board" before flashing and the outputs were identical, but I don't know if that covers the protection and flash sufficiently, if at all.

I did try to verify the new 328P with the hex shipped with the IDE before I flashed it and it failed but figured that could be the Adafruit hex vs the one shipped with Arduino 1.0 IDE.

[westfw]

It would most likely be the protection of the flash in the 328p that caused problems. the 16u chip is normally just the USB/Serial converter where "nothing can go wrong. go wrong. go wrong."

[phineasjw]

I fought through this problem off and on for a couple days. My company has 1000 blank Arduino Ethernet's coming in and I didn't enjoy the thought of programming them with ArduinoAsISP - since I guesstimated I would be looking at about 17hrs to program them.

I finally came to the same conclusion that is was a fuse setting relative to clock speed. My working theory was that the default setting on blank chips was using a different speed than the CLOCKSPEED_FUSES value in the optiboot.h file - thus causing the fuse setting stage to fail, preventing the rest of the programming process from working. The optiboot.h file was set to #define CLOCKSPEED_FUSES SPI_CLOCK_DIV128. There is a comment in there about fiddling with this speed but the comment about the internal crystal threw me off because our boards have external crystals.

At any rate, in desperation I changed it to #define CLOCKSPEED_FUSES SPI_CLOCK_DIV64 and now the fuses get programmed correctly allowing the standalone programmer to work as expected. I would love for someone to explain to me the clock math reason that makes it work. The default fuse setting on these chips is 0x62 (01100010)



I have to assume that the reason the standalone programmer worked on previously programmed parts is that the low fuse was already set to match the actual clock.

I also changed the image to the latest version of optiboot (5.0) and all is well. Next up is to use this code to then load blink code to give a quick visual indication that the micro is alive.

Now I should be able to program a 1000 arduino ethernet's in 1.5hrs or so.

Hope this fix saves others some frustration.