avrdude: verification error, first mismatch at byte 0x1e000 0xff != 0x0d
cd\cd\ArduinoBuilder\code\Blinkavrdude -v -p atmega2560 -c usbasp -U lfuse:w:0xc2:m -U hfuse:w:0x99:m -U efuse:w:0xff:m -U lock:w:0x3f:m -U flash:w:Blink.hex
avrdude -v -p atmega2560 -c USBasp -U lfuse:w:0xFF:m -U hfuse:w:0xD8:m -U efuse:w:0xFD:m -U lock:w:0x0F:m -U flash:w:Blink.hex
The differences between the two sets of fuses are:- The first one assumes there is an external clock source in form of a crystal on your board, the second uses the internal RC oscillator for clocking the AVR.- The first one sets the AVR to start executing a so called bootloader (a program stored in a special part of the AVR, that in turn will communicate over some arbitrary media and program the application proper into the rest of the flash). The second one does not have this bootloader set.-The second one had disable "brown-out detection", a way for the AVR to detect low voltage conditions and to do a reset if one has occurred.
avrdude: verification error, first mismatch at byte 0x1e000 0xff != 0x0davrdude: verification error; content mismatch
I think it's actually worse. I think it's a coding error. avrdude is not taking the extended addressing into account when it verifies. I wonder if the same thing would happen on an Atmega2561, or is it limited to the 2560, which is just a extended addressing version of the 1260. 0x1E000 is where the bootloader goes on the Atmega1260. Anyway, it's something they should fix, but if they did it may be a while until it gets into the Arduino release which is always quite far behind on its version of avrdude.
I think you'd get the same error if you loaded a program of over 131072 bytes in length without the bootloader.