Go Down

Topic: Why, oh why? verification error, first mismatch at byte 0x00c5 0x90 != 0x94 (Read 518 times) previous topic - next topic

arakon

I have an Atmega 2560 "Pro Embed" here, basically a small Atmega2560 board similar to a nano, just for the 2560.
When using the stock bootloader, the RX0 pin is completely dead. Using the Optiboot bootloader, RX0 works, I can upload etc.. however, any sketch I write will result in this:
Code: [Select]

Reading | ################################################## | 100% 0.38s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x00c5
        0x90 != 0x94
avrdude: verification error; content mismatch


The address and error is always identical, no matter the sketch.. AND the sketch is working perfectly fine from what I can tell.
Any clue on this one?

Coding Badly


arakon

The fuses match what the Optiboot settings dictate.

E:FD, H:D6, L:F7 for optiboot_flash_atmega2560_UART0_115200_16000000L_B7_BIGBOOT.hex.


arakon

I'm using the Arduino IDE (latest stable version), so I would assume so.

Coding Badly


arakon

I did, yes.
Using the boards manager with the correct link for the latest Mega/Microcore, too.

Coding Badly


arakon

I had to attach the verbose log as it's too long to post.
It contains both the flashing of the bootloader log, and the writing of the sketch.

DrAzzy

Which bootloader are you using? The one from MCUdude's MegaCore?

mmmm... isn't that frequently a reset issue? Does it have an LED on the right pin that does the optiboot tripleblink? If so, does it do that in the middle of the verification process? (if yes, then it's resetting for some reason at that point)
ATTinyCore for x4/x5/x61/x7/x8/x41/1634/828/x313 megaTinyCore for the megaavr ATtinies - Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

arakon

Yep, that's the bootloader I am using.
It takes a very short time between verification and rebooting the controller, I can't entirely be sure if the flashing has anything to do with it.

Edit: I uploaded a larger sketch and the location of the verify error shifts. However, running another verify afterwards against the hex shows yet another location.. the location is always the same on flashing and on verifying, but differs between the two operations.
With the larger sketch, the bootloader flashes don't happen until just after verification finishes, it seems. So I don't think it's resetting mid-verify.


Coding Badly


Do you burn the bootloader each time or did you post two logs combined together?


arakon

They're combined, just to show that the BL burns correctly and with the proper fuses.

kprims

Could you Use Sketch:Upload using programmer, with the USBasp hooked up? Would be interesting to see if you still get a verification failure on different sketches.
Remember this will wipe the bootloader and you will need to reburn it when loading sketches the regular way.

arakon

No verification errors when uploading it that way... buuut.. it also doesn't start. Power LED on the board is on, but that's it, no LED blinking as the sketch would cause, no serial output from the sketch either.

Go Up