Go Down

Topic: avrdude content mismatch: Linux, ATMEGA328 (Read 5801 times) previous topic - next topic

michael shiloh

Platform: Ubuntu Linux
IDE rev: 13 alpha
Arduino: Duemilanove with ATMEGA328

Error:
avrdude: verification error, first mismatch at byte 0x0006
       0x8d != 0x7d
avrdude: verification error; content mismatch

But there are two weird things:

1. It worked OK at first, through about a dozen downloads, then suddenly started exhibiting this problem.

2. A different board of the same revision is showing no problems when
uploaded from a Windows computer running rev 14. However, my board, shows the same problem on Windows.

Is it possible I've corrupted the boot loader?

There has been a long thread on the forums about an avrdude protocol
error, and I think I may have seen this occur a few times. In the
forums, there are many proposed explanations and fixes. Most assume
problems with the Windows port (not my problem), but some suggest manual reset before upload. This did not help me.

At first I suspected a problem with the Linux version 13 alpha, but now
I'm not so sure.

Suggestions?


mellis

It sounds like there's flakey communication somewhere, not a fundamental problem in the setup.  Is the error message always exactly the same (i.e. the same byte number)?

I'm guessing there's a loose solder job somewhere on the board.  You should be able to get it replaced by the distributor that you bought it from.

michael shiloh


michael shiloh

Well, it's been a long time but I finally bought and built a USBTinyISP. I've used it to try to reprogram the boot loader, and guess what: I get the same error:

avrdude: verification error, first mismatch at byte 0x0000
        0x3f != 0x0f
avrdude: verification error; content mismatch

It's always the same error: same address, same byte value.

I'm using the USBTinyISP to power the Arduino.

Any ideas?

Michael

trialex

Are you 200% sure you've got the right chip selected in the Tools -> Board menu?

If you bought the ATmega328 separately remember the '328 is not the same as the '328P

retrolefty

#5
Jun 26, 2009, 05:12 am Last Edit: Jun 26, 2009, 05:13 am by retrolefty Reason: 1
Quote
If you bought the ATmega328 separately remember the '328 is not the same as the '328P


I've only seen 328P data sheet. Is there such a device as a '328?

Lefty

trialex

Yeah now that I think of it, not sure. I think maybe I was thinking of when you use avrdude from the command line, there is a difference and you need to select the part as '328P.

Still, check that the board you have selected is Arduino with 328, not just Duemilanove

gzip

I was having the same problem and it turned out to be a power issue. A switch from USB power to wall wart solved it. I had a similar problem when I first built my Arduino. I could program Atmega8s but it would fail on Atmeg168. I was using a 9v battery at the time.

CaptainObvious

Very interesting.

I haven't tried the power issue yet, but I have noticed I only get the error when I'm trying to use a (HUGE), well bitmap that was converted into a .h file, it uses PROGMEM.

avrdude: verification error, first mismatch at byte 0x0080
        0xff != 0x05
avrdude: verification error; content mismatch

Once I upload normally to the board.. using a different sketch with the LCD, it works fine.

And actually.. when I uploaded a sketch that included a different .h file, the bootloader locked up on me completely. (I was able to able to lock it up multiple times, just to make sure) I'm guessing it was some kind of memory error? I don't have much experience with PROGMEM, I have read up on the Playground and some random sites but not sure how to get it to work in my position.

I did just try with an external wall-wart, regulated at 11.49 ish volts, can supply 1.5 amps... without any luck, still get the error when I upload the first sketch. (Keep in mind, it does say it's done uploading, and the LCD initializes.. but it doesn't print the picture, which is error in the code I'm positive.


Just curious, did you try different sketches when you were testing? For example using just the Blink example? Just to rule out anything with memory leaks. (I know they say it's not very easy to lock up the Arduino like this.. but I just did, repeatedly lol, inexperience for the win!)

Elbriga

You must set the baud rate for the 328(p) chip with " -b 57600 " on the avrdude line

Go Up