I want to burn a hex file to a custom ATmega2560 board. I use this USBasp programmer for flashing (firmware version 1.01) on my Mac OS X 10.12.6 system. All hex files are compiled with avr-gcc (GCC) 4.9.2.

I use this command to burn fuses (without bootloader):

/Applications/Arduino.app/Contents/Java/hardware/tools/avr/bin/avrdude -C/Applications/Arduino.app/Contents/Java/hardware/tools/avr/etc/avrdude.conf -v -patmega2560 -cusbasp -Pusb -U lfuse:w:0xff:m -U hfuse:w:0xd9:m -U efuse:w:0xfd:m -s -F

What is working fine: I can flash smaller (43,266 bytes) programs and they work straight away without bootloader. If I flash bigger programs (99,986 bytes) they do not run. I can verify if the program runs because they spit out data via TTL. The smaller program does work but the bigger one does not produce anything.

I turned on "Code verify" and I can see for smaller programs:

avrdude: 43264 bytes of flash verified

big programs:

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

Any hints on this side?

Secondly: after deleting the whole flash, when I flash a custom bootloader (from Atmel Studio - fuses are Ext. 0xFD, High: 0xD2, Low: 0xFF), command:

/Applications/Arduino.app/Contents/Java/hardware/tools/avr/bin/avrdude -C/Applications/Arduino.app/Contents/Java/hardware/tools/avr/etc/avrdude.conf -v -patmega2560 -cusbasp -Pusb -U flash:w:ATmega_Example.hex:i

and afterwards read the flash, the bootloader ended up in several blocks within the flash.

From the readout hexfile (data blocks):

Line 1


All the flash is 0xFF until Line 1921


Some more data until Line 1995.


All the flash is 0xFF until Line 3970.


Some more data until Line 4044.


And so on... I can find similar data 4 times in the file.

Is this a problem with the flashing or with reading the data from the chip?

Let me know if you need more information to help me here.

  • any change if using -D flag?
    – neu-rah
    Commented Dec 11, 2017 at 7:18
  • no change when I flash with the "-D" option
    – jblaze
    Commented Dec 11, 2017 at 7:30
  • 1
    Define "smaller" and "bigger" wrt the code size. Commented Dec 11, 2017 at 7:34
  • small: 43.266 bytes big: 99.986 bytes
    – jblaze
    Commented Dec 11, 2017 at 7:47
  • I added verification information. On bigger problems it fails: avrdude: verification error, first mismatch at byte 0x0001 0x90 != 0x94 avrdude: verification error; content mismatch
    – jblaze
    Commented Dec 11, 2017 at 8:24

3 Answers 3


Personally I use AVRDUDESS for uploading sketch on atmega328p and attiny85. Try to use it and run detect. I answer this because AVRDUDESS is very easy to use and it can help you to show more info of your error. I think you maybe have a bad wiring or a defect cable.


I'm not certain that it's going to fix your problem, but few years ago I had similar issue. I was trying to upload program to ATTiny13A using cheap e-bay USPasp and got verification errors. One step of my solution was changing programmer id from "-c usbasp" to "-c usbasp-clone"

More here: https://www.nongnu.org/avrdude/user-manual/avrdude_4.html

USBasp vs USBasp-clone


I am familiar with that issue. I don't have an USBasp but an USBtinyISP but I think the problem is the same.

The USBtinyISP cannot read or write past 64kiB. Since AVR are 8-bit machines with 16-bit addressing they cannot address past 64kiB on their own. A special addressing schema is used on runtime and also during flash. (I think it was larger page sizes during flash.)

I could manage to get around the issue by using an original Atmel AVRISP mkII.

Your Answer

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

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