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?

user3042719
  • 151
  • 1
  • 3
  • I added some serial output to my program and it seems to work correctly though... What? – user3042719 Feb 04 '15 at 02: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 04 '15 at 16:48
  • @AnnonomusPenguin I have, multiple times. It still persists. – user3042719 Feb 04 '15 at 22:31
  • Sounds like a possibility of a defective board... – Anonymous Penguin Feb 04 '15 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 '16 at 13:13

2 Answers2

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.

Nick Gammon
  • 35,792
  • 12
  • 63
  • 121
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.

user23265
  • 1