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:
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?
Failed to correctly set the fuses?
The fuses match what the Optiboot settings dictate.
E:FD, H:D6, L:F7 for optiboot_flash_atmega2560_UART0_115200_16000000L_B7_BIGBOOT.hex.
I'm using the Arduino IDE (latest stable version), so I would assume so.
Did you use the IDE to install the bootloader?
I did, yes.
Using the boards manager with the correct link for the latest Mega/Microcore, too.
Post the verbose output. Maybe that will reveal a hint.
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.
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)
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.
Do you burn the bootloader each time or did you post two logs combined together?
They're combined, just to show that the BL burns correctly and with the proper fuses.
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.
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.
Check around the Reset circuit. Make sure you have around 5V on the reset lead after the sketch is loaded.
buuut.. it also doesn't start.
You will have to adjust the fuses / lock bits to reflect the absence of a bootloader.
Why? Unless you want extra memory, it seems to work well here. Load the sketch using USBasp, then plug your Mega into the USB and get your serial messages. Blinking away and dumping the message.
Mega 2560 IN LOOP
...it seems to work well here...
I believe the vector table is the most important difference. I recall something about the reset vector pointing to no-man's-land. You know. The bit of start up logic that, if it does not work as expected, might lead someone to post something like, "buuut.. it also doesn't start."
I changed the high fuse from D6 to D7 to indicated a lack of bootloader, with the same result. The sketch will not start. I also tried to upload it with the original Arduino 2560 board settings instead of the MegaCore one, with the same result.
So, to summarize:
- Upload over ISP works without verification error, but code will not start
- Upload via serial using the MegaCore bootloader causes a verification error, but code starts.
- Upload via serial using the stock bootloader causes RX0 to be completely non-functional
Most likely theory at this point: Goblins.
Will check the reset pin voltage in the morning.