5

I bought a SainSmart Arduino Mega 2560. I uploaded a small sketch to it, and it uploaded fine. When I upload a larger sketch though, I get this error:

verification error, first mismatch at byte 0x3895
         0xdf != 0x44

So obviously there's nothing wrong with my bootloader because I can upload smaller files. Why is this happening?

Improve this question
5
  • I added some serial output to my program and it seems to work correctly though... What?
    – user3042719
    Feb 4, 2015 at 2:42
  • It seems like it was a bad upload for some odd reason. Retry uploading the sketch that gave you that error and see if it persists.
    – Anonymous Penguin
    Feb 4, 2015 at 16:48
  • @AnnonomusPenguin I have, multiple times. It still persists.
    – user3042719
    Feb 4, 2015 at 22:31
  • Sounds like a possibility of a defective board...
    – Anonymous Penguin
    Feb 4, 2015 at 22:32
  • Is the error address always the same or does it change? Try uploading a different larger sketch, maybe one of the examples that pulls in a library or two. Does the reported error occur at the same address? That could mean a defect in the chip's flash memory. You might also try deliberately generating code containing either of the problem cases @NickGammon mentions and see if either of those causes the same error. That would suggest your larger sketch contains one of them.
    – JRobert
    Feb 22, 2016 at 13:13

2 Answers 2

Reset to default
1

If your sketch contains !!! in it, that can cause some versions of the bootloader to drop into interactive mode, eg.

Serial.println ("Rocket firing!!!");

Also there can be problems with 0xFF bytes in your code causing the bootloader to incorrectly assume that that page of memory was erased, when it was not.

I have a bootloader-uploader sketch at: Atmega bootloader programmer

You need a second board to use it (eg. a Uno) - the bootloader for the Mega2560 is a reasonably up-to-date one. I haven't actually tested it with the Sainsmart version of the Mega, but I presume that internally that part is the same.

Improve this answer
0

I believe I have finally understood this error today, and would like someone to verify or refute.

In "avrdude.conf" there is defined for each processor and for each memory type a minimum duration and a maximum duration that the programmer will repeat trying to write each byte. These have values of "min_write_delay = 4500" and "max_write_delay = 4500" (no idea what the units are).

After increasing the max_write_delay to "max_write_delay = 16000" (arbitrary increase but keeping it less than a 16 bit signed integer to avoid buffer overflow risks), for all memory types (but I would presume that only "flash" memory needs the parameter to be altered) my Arduino takes an extra 30 seconds to program, but no more verification errors.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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