[bug #48261] STK500V2 ISP problem with ATmega8/8515/8535, ATmega16 and ATmega32

[avrs-admin]

Johnny Quest scotty264b@gmx.com Sat 18 Jun 2016 04:51:15 AM UTC

Hello: First off, I have done my homework on this matter and would not have posted seeking assistance unless it was a last resort.  smiley

This message was posted on AVR FREAKS. http://www.avrfreaks.net/forum/atmega32a-avr-dragon-programming-flaky-ness

Background:  Ex-disti-FAE for ATMEL as one of my support lines.  Very familiar with ATmega48/88/168/328, ATtiny25/45/85, ATmega32U4, AT90USB1286 (and somewhat on the ATmega2560).

Development environment:  Using Linux for development running AVR STUDIO in a "Virtual WINDOWS" environment.   AVRDUDE V6.3 for Linux.  ATmega32A, 16MHz external crystal, VCC = 5V (PwrSup is 1A capable).  Fuses set for external high-freq crystal, bootloader at 0x7E00, bootloader reset enabled (lfuse = 0x8F   hfuse = 0x96).

Quandary: developing code for ATmega32A; when using AVRDUDE to program FLASH using ISP with "DRAGON_ISP" programmer, AVRDUDE fails with:

avrdude: verification error, first mismatch at byte 0x7e00 0xff != 0x0f

---

Command line invokation is:

avrdude -u -p m32 -c dragon_isp -B 1MHz -U flash:w:AVR_Specific_Builds/m32/ATTOBASICV234_m32-16MHZ-uart_btldr.hex

---

Partial dump from original HEX file around address 0x7E00: :107D00000000000000000000000000000000000073 :107D10000000000000000000000000000000000063 :107D20000000000000000000000000000000000053 :107D30000000000000000000000000000000000043 :107D40000000000000000000000000000000000033 :107D50000000000000000000000000000000000023 :107D60000000000000000000000000000000000013 :107D70000000000000000000000000000000000003 :107D8000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF03 :107D9000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3 :107DA000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE3 :107DB000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD3 :107DC000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC3 :107DD000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB3 :107DE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA3 :107DF000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF93 :107E00000F92CDB7DEB711248FE598E09EBF8DBFEE :107E100084B714BE81FFD6D085E08EBD82E08BB9D9 :107E200088E18AB986E880BD80E189B98EE0B5D065 :107E3000BD9A26E080E39CEF54E040E29DBD8CBDFE :107E400058BF08B602FEFDCF38B3342738BBA8951B :107E50002150A1F788249924CC24C394F5E0DF2E87 :107E6000E1E1EE2E73E0F72E91D0813469F48ED0EB :107E7000898398D08981823811F1813811F485E0A5 :107E800001C083E07FD07BC0823411F484E103C061 :107E9000853419F485E08ED072C0853561F476D0D2 :107EA000082F10E073D090E0982E8824802A912A21 :107EB000880C991C63C0863521F484E07BD080E077 :107EC000E1CF843609F03FC061D060D0B82E5ED0DB :107ED00080E0881680E7980618F4F401F7BEE8956C :107EE00000E610E053D0F80181938F01BA94D1F7E6 :107EF000F0E08F16F0E79F0618F0F401F7BEE89562

Addresses 0x7D00 to 0x7DFF is waveform data for DDS function.

---

After failure, partial dump of reback of FLASH memory around address 0x7E00.  Even the data starting at 0x7D00 is incorrect. :107D0000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF83 :107D1000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF73 :107D2000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF63 :107D3000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF53 :107D4000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF43 :107D5000FFFF000000000000000000000000000025 :107D60000000000000000000000000000000000013 :107D70000000000000000000000000000000000003 :107D8000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF03 :107D9000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3 :107DA000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE3 :107DB000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD3 :107DC000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC3 :107DD000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB3 :107DE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA3 :107DF000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF93 :107E0000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF82 :107E1000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF72 :107E2000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF62 :107E3000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF52 :107E4000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF42 :107E5000FFFFA1F788249924CC24C394F5E0DF2EFA :107E6000E1E1EE2E73E0F72E91D0813469F48ED0EB :107E7000898398D08981823811F1813811F485E0A5 :107E800001C083E07FD07BC0823411F484E103C061 :107E9000853419F485E08ED072C0853561F476D0D2 :107EA000082F10E073D090E0982E8824802A912A21 :107EB000880C991C63C0863521F484E07BD080E077 :107EC000E1CF843609F03FC061D060D0B82E5ED0DB :107ED00080E0881680E7980618F4F401F7BEE8956C :107EE00000E610E053D0F80181938F01BA94D1F7E6 :107EF000F0E08F16F0E79F0618F0F401F7BEE89562

---

All other ATmega devices program properly using ISP and JTAG, without incident, so I do not believe it is the DRAGON.  The ATmega32A programs properly using JTAG with AVRDUDE and DRAGON, only ISP fails using AVRDUDE.  Using DRAGON (1MHz sck) under AVR STUDIO, ISP programming is successful.

I have tried ISP with USBASP and USBtinyISP as well and they function correctly.

I have tried with V6.3, V6.2 V6.0 of AVRDUDE.  V5.x versions fail to communicate with DRAGON due to "parallel port connection error" (?????DRAGON is USB!!)  I have looked at the avrdude.conf for other "compatible devices" and found ATmega328p and ATmega329 are accurate.  Using AVRDUDE "-F" switch produces the same verification failure with these two part definitions.

I have tried various "-B" settings for AVRDUDE to no avail. I have tried using external 8MHz crystal to no avail. I have tried using internal 8MHz oscillator to no avail.

I have four (4) NEW ATmega32A's, none are blown as I can successfully program all of them using JTAG, USBtinyISP and USBasp but using DRAGON_ISP, all fail in the same manner.

Chinese fakes?  I do not see how as these parts do not look like it. They have ATMEL logo and date code of "1508".

Is this an AVRDUDE issue, an ATmega32A issue or combination of both?

Does anyone have any answers, ideas or clues to offer?

Thank you in advance.

Peace and blessings, Scott

file #37526: ATTOBASICV234_m32-16MHZ-uart_btldr.hex file #37550: ATTOBASICV234_m16-16MHZ-uart_btldr.hex

This issue was migrated from https://savannah.nongnu.org/bugs/?48261

[avrs-admin]

Scott Vitale Wed 22 Jun 2016 06:53:34 PM UTC

Hello: As a further test, I recently ordered and received two (2) ATmega16A's.  Using the same test conditions, but uploading a 16KB image to FLASH, I receive the same "verification error" as I did with the ATmega32A's.  Again, the failure is complained about at the bootloader's selected address.  The clock speed is 16MHz, external crystal.  Here is the command line invocation and subsequent error message.  0x3e00 is the selected start address of the bootloader via the fuse settings.

avrdude -u -p m16 -c dragon_isp -B 500kHz -U flash:w:ATTOBASICV234_m16-16MHZ-uart_btldr.hex

"avrdude: verifying ... avrdude: verification error, first mismatch at byte 0x3e00 0xff != 0x0f avrdude: verification error; content mismatch "

I will upload the original file for this one as well.

Peace and blessings, Johnny Quest

[avrs-admin]

Scott Vitale Sat 25 Jun 2016 04:35:40 PM UTC

Thought this might be helpful.

My AVR DRAGON: Hardware Revision: 0x107, Firmware Version: 0x610610

BTW:  The original HEX file was generated by AVRASM.EXE (from AS 4.19).

I also recently generated and tested with with two 32KB files. one filled with all 0x00's and the other with random values.  Both programmed properly on my setup.

Thinking that missing data between unused address ranges was a contributing factor,  I used srec_cat to fill in the missing address ranges of my original test file with 0x00's and again with 0xFF's to generate two separate full 32KB address files.  Once again, avrdude + DRAGON_ISP failed.

Discussion is here: http://www.avrfreaks.net/comment/1916896#comment-1916896

Also, This error was confirmed by some one else for me.  The specifics for his setup are AVRDUDE 6.1 with ATmega32 (non "A").

Discussion is here: http://www.avrfreaks.net/comment/1917241#comment-1917241

[mcuee]

Not so sure if this is still relevant or not. I have the AVR Dragon but not the M32 or M32A for testing. Interestingly the avrfreaks thread also says Dragon is flaky.

[MCUdude]

I'll give it a try later today with an ATmega32.

The dragon is indeed very flakey. Some information here: http://www.aplomb.nl/TechStuff/Dragon/Dragon.html

Three main reasons:

1. The Dragon is USB-powered, and has a step-up converter on board to generate 12V for the HV-programming. However, when touching the area where this circuit located (down-left corener on the picture), causes the voltage to go up, and that's fatal. Dragon DEAD.
2. Powering the Dragon from a USB-port that is not "prepared" to deliver the 850 mA rush-in current, causes the step-up coverter to die, because of the sudden drop of the USB-supply voltage.
3. If the Dragon is connected to a faulty board (sh*t happens ...), it's interface isn't rugged enough to withstand that abuse.

Since we know this, .... time for some action.

1. Solution is simple: don't touch the Dragon in that area. And how to accomplish that ? Give it a proper housing.
2. Not all PC-USB-ports can deliver the rush-in current, and failing to do so means ..... ah, we know that now. Solution: Power the Dragon from an USB-hub with an external, beefy power-supply.
3. Add a buffer that can withstand that abuse.

[MCUdude]

I can confirm that there's something going on with the dragon.

Here are the ATmega32's fuse settings:

``` $ ./avrdude -p atmega32 -c usbasp -Ulfuse:r:-:h -Uhfuse:r:-:h avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.00s avrdude: Device signature = 0x1e9502 (probably m32) avrdude: reading lfuse memory: Reading | ################################################## | 100% 0.00s avrdude: writing output file "" 0x8f avrdude: reading hfuse memory: Reading | ################################################## | 100% 0.00s avrdude: writing output file "" 0x96 avrdude done. Thank you. ```

---

Here is OPs hex file written with an AVR dragon (fails):

**Dragon non-verbose output:**

``` $ ./avrdude -p atmega32 -c dragon_isp -Uflash:w:/Users/hans/Downloads/ATTOBASICV234_m32-16MHZ-uart_btldr.hex avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.15s avrdude: Device signature = 0x1e9502 (probably m32) avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: reading input file "/Users/hans/Downloads/ATTOBASICV234_m32-16MHZ-uart_btldr.hex" avrdude: input file /Users/hans/Downloads/ATTOBASICV234_m32-16MHZ-uart_btldr.hex auto detected as Intel Hex avrdude: writing flash (32768 bytes): Writing | ################################################## | 100% 12.89s avrdude: 32768 bytes of flash written avrdude: verifying flash memory against /Users/hans/Downloads/ATTOBASICV234_m32-16MHZ-uart_btldr.hex: avrdude: input file /Users/hans/Downloads/ATTOBASICV234_m32-16MHZ-uart_btldr.hex auto detected as Intel Hex Reading | ################################################## | 100% 12.40s avrdude: verification error, first mismatch at byte 0x7e00 0xff != 0x0f avrdude: verification error; content mismatch avrdude done. Thank you. ```

**Dragon verbose output:**

It turned out that the output was so long that it exceeded the maximum amount of character a single post can have. You can find the complete output here: https://gist.github.com/MCUdude/bfb62a7c16316bb88778b92313749824

---

Here's OPs hex file written with a USBasp (succeeds):

``` $ ./avrdude -p atmega32 -c usbasp -Uflash:w:/Users/hans/Downloads/ATTOBASICV234_m32-16MHZ-uart_btldr.hex avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.00s avrdude: Device signature = 0x1e9502 (probably m32) avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: reading input file "/Users/hans/Downloads/ATTOBASICV234_m32-16MHZ-uart_btldr.hex" avrdude: input file /Users/hans/Downloads/ATTOBASICV234_m32-16MHZ-uart_btldr.hex auto detected as Intel Hex avrdude: writing flash (32768 bytes): Writing | ################################################## | 100% 4.08s avrdude: 32768 bytes of flash written avrdude: verifying flash memory against /Users/hans/Downloads/ATTOBASICV234_m32-16MHZ-uart_btldr.hex: avrdude: input file /Users/hans/Downloads/ATTOBASICV234_m32-16MHZ-uart_btldr.hex auto detected as Intel Hex Reading | ################################################## | 100% 2.51s avrdude: 32768 bytes of flash verified avrdude done. Thank you. ```

---

To my surprise, the AVRISPmkII also fails:

``` $ ./avrdude -p atmega32 -c avrispmkii -Uflash:w:/Users/hans/Downloads/ATTOBASICV234_m32-16MHZ-uart_btldr.hex avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.01s avrdude: Device signature = 0x1e9502 (probably m32) avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: reading input file "/Users/hans/Downloads/ATTOBASICV234_m32-16MHZ-uart_btldr.hex" avrdude: input file /Users/hans/Downloads/ATTOBASICV234_m32-16MHZ-uart_btldr.hex auto detected as Intel Hex avrdude: writing flash (32768 bytes): Writing | ################################################## | 100% 18.16s avrdude: 32768 bytes of flash written avrdude: verifying flash memory against /Users/hans/Downloads/ATTOBASICV234_m32-16MHZ-uart_btldr.hex: avrdude: input file /Users/hans/Downloads/ATTOBASICV234_m32-16MHZ-uart_btldr.hex auto detected as Intel Hex Reading | ################################################## | 100% 17.64s avrdude: verification error, first mismatch at byte 0x7e00 0xff != 0x0f avrdude: verification error; content mismatch avrdude done. Thank you. ```

---

@dl8dtl do you have any idea why the Dragon and the AVRISPmkII fail?

[MCUdude]

Interesting!

If I remove the following part of the hex file, located between the user program and the bootloader section, it works with both the Dragon and the AVRISPmkII...

 :10385000666F756E642120000000FBFD61206269C7
 :103860006E617279206E756D62657200FB496E76CD
 :10387000616C6964206E756D626572206F6620618F
 :103880007267756D656E74732E000000FB204576BF
 :10389000656E2061646472657373206F6E6C79214C
 :0438A0002000189557
 :107D00000000000000000000000000000000000073
 :107D10000000000000000000000000000000000063
 :107D20000000000000000000000000000000000053
 :107D30000000000000000000000000000000000043
 :107D40000000000000000000000000000000000033
 :107D50000000000000000000000000000000000023
 :107D60000000000000000000000000000000000013
 :107D70000000000000000000000000000000000003
-:107D8000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF03
-:107D9000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3
-:107DA000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE3
-:107DB000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD3
-:107DC000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC3
-:107DD000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB3
-:107DE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA3
-:107DF000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF93
 :107E00000F92CDB7DEB711248FE598E09EBF8DBFEE
 :107E100084B714BE81FFD6D085E08EBD82E08BB9D9
 :107E200088E18AB986E880BD80E189B98EE0B5D065
 :107E3000BD9A26E080E39CEF54E040E29DBD8CBDFE
 :107E400058BF08B602FEFDCF38B3342738BBA8951B

[mcuee]

Interesting I got verfication error with my newly bough Arduino Mega2560 clone (with CH340) and initially I also got verification error with an hex file (exported from Arduino blinky example). And Arduino itself also has the verification error message after followed by stk500v2 timeout error.

But then I tried to program the official bootloader again and then try again with avrdude and Arduino, both are now okay. Maybe the clone board is flashed with bad bootloader which somehow interferes the operation of avrdude. It does not seem to have 0xFF in between the bootloader and the application though. SO the issue may be different.

Sorry I did not read out the original bootloader written so I can not upload that faulty bootloader.

Edit: my issue is not relevant. Sorry for the noise.

[MCUdude]

@dl8dtl you're probably the one that knows the source code the best. How can one type of programmer (USBasp) work with OPs hex files, while others (AVRISPmkII, Dragon ISP) don't? Is this related to the programmer hardware/firmware, or does Avrdude treat these programmers differently in terms of what's "legal" to write?

[dl8dtl]

Sounds to me like a bug in the stk500v2 code (which is used for Dragon, STK500, AVRISPmkII and so on).

[mcuee]

Not so sure if it is to do with the boot_start handling in stk500v2.c, but it is supposedly to be used only for xmega.

[mcuee]

I do not have the ATmega32A, not so sure if I can test with ATmega328P or not.

[mcuee]

I just got an ATmega32A board running MightyCore.

Tested with an AVRISP mkii clone, I can reproduce the issue.

PS C:\work\avr\avrdude_test\avrdude-7.0_bin64> .\avrdude -p atmega32a -c stk500v2 -P COM6 
-Ulfuse:r:-:h -Uhfuse:r:-:h

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.09s

avrdude.exe: Device signature = 0x1e9502 (probably m32a)
avrdude.exe: reading lfuse memory:

Reading | ################################################## | 100% 0.03s

avrdude.exe: writing output file "<stdout>"
0x8f
avrdude.exe: reading hfuse memory:

Reading | ################################################## | 100% 0.03s

avrdude.exe: writing output file "<stdout>"
0x96

avrdude.exe done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude-7.0_bin64> .\avrdude -p atmega32a -c avrispmkii 
-U flash:w:ATTOBASICV234_m32-16MHZ-uart_btldr.hex:i

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude.exe: Device signature = 0x1e9502 (probably m32a)
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
             To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file "ATTOBASICV234_m32-16MHZ-uart_btldr.hex"
avrdude.exe: writing flash (32768 bytes):

Writing | ################################################## | 100% 3.45s

avrdude.exe: 32768 bytes of flash written
avrdude.exe: verifying flash memory against ATTOBASICV234_m32-16MHZ-uart_btldr.hex:

Reading | ################################################## | 100% 2.84s

avrdude.exe: verification error, first mismatch at byte 0x7e00
             0xff != 0x0f
avrdude.exe: verification error; content mismatch

avrdude.exe done.  Thank you.

However, I can not reproduce the issue with an STK500v2 clone. That is strange.

PS C:\work\avr\avrdude_test\avrdude-7.0_bin64> .\avrdude -p atmega32a -c stk500v2 -P COM6 
-U flash:w:ATTOBASICV234_m32-16MHZ-uart_btldr.hex:i

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.08s

avrdude.exe: Device signature = 0x1e9502 (probably m32a)
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
             To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file "ATTOBASICV234_m32-16MHZ-uart_btldr.hex"
avrdude.exe: writing flash (32768 bytes):

Writing | ################################################## | 100% 4.66s

avrdude.exe: 32768 bytes of flash written
avrdude.exe: verifying flash memory against ATTOBASICV234_m32-16MHZ-uart_btldr.hex:

Reading | ################################################## | 100% 3.94s

avrdude.exe: 32768 bytes of flash verified

avrdude.exe done.  Thank you.

[mcuee]

Interesting!

If I remove the following part of the hex file, located between the user program and the bootloader section, it works with both the Dragon and the AVRISPmkII...

@MCUdude And yes I can reproduce the same thing with my AVRISP mkii clone (this looks like a good clone which works under Atmel Studio 7).

PS C:\work\avr\avrdude_test\avrdude-7.0_bin64> .\avrdude -p atmega32a -c avrispmkii 
-U flash:w:ATTOBASICV234_m32-16MHZ-uart_btldr_ok.hex:i

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude.exe: Device signature = 0x1e9502 (probably m32a)
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
             To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file "ATTOBASICV234_m32-16MHZ-uart_btldr_ok.hex"
avrdude.exe: writing flash (32768 bytes):

Writing | ################################################## | 100% 3.41s

avrdude.exe: 32768 bytes of flash written
avrdude.exe: verifying flash memory against ATTOBASICV234_m32-16MHZ-uart_btldr_ok.hex:

Reading | ################################################## | 100% 2.84s

avrdude.exe: 32768 bytes of flash verified

avrdude.exe done.  Thank you.

[mcuee]

I can reproduce the issue with a more exact clone of STK500v2 (which uses ATmega8535 and support high voltage programming). It uses an old USB to serial chip and does not work well under Windows so I tested this under Linux (Ubuntu 20.04).

mcuee@UbuntuSwift3:~/build/avr$ avrdude -c stk500v2 -P /dev/ttyUSB1 -p atmega32a  
-Ulfuse:r:-:h -Uhfuse:r:-:h

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9502 (probably m32a)
avrdude: reading lfuse memory:

Reading | ################################################## | 100% 0.00s

avrdude: writing output file "<stdout>"
0x8f
avrdude: reading hfuse memory:

Reading | ################################################## | 100% 0.00s

avrdude: writing output file "<stdout>"
0x96

avrdude done.  Thank you.

mcuee@UbuntuSwift3:~/build/avr$ avrdude -c stk500v2 -P /dev/ttyUSB1 -p atmega32a  
-U flash:w:./ATTOBASICV234_m32-16MHZ-uart_btldr.hex:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9502 (probably m32a)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "./ATTOBASICV234_m32-16MHZ-uart_btldr.hex"
avrdude: writing flash (32768 bytes):

Writing | ################################################## | 100% 3.64s

avrdude: 32768 bytes of flash written
avrdude: verifying flash memory against ./ATTOBASICV234_m32-16MHZ-uart_btldr.hex:

Reading | ################################################## | 100% 1.78s

avrdude: verification error, first mismatch at byte 0x7e00
         0xff != 0x0f
avrdude: verification error; content mismatch

avrdude done.  Thank you.

[mcuee]

Then I have another STK500v2 clone using a 8051 CPU (STC STC15W1K16S) which also claims to support HVSP/HVPP, and it does not have this issue. Looks like this one and the previous STK500v2 clone may not follow exactly the official STK500 FW.

And then the AVeRISP mkii clone and the STK500v2 clone using ATmega8535 (which also claims to support HVSP/HVPP) seem to follow the official FW.

mcuee@UbuntuSwift3:~/build/avr$ avrdude -c stk500v2 -P /dev/ttyUSB1 -B 1 -p atmega32a  
-U flash:w:./ATTOBASICV234_m32-16MHZ-uart_btldr.hex:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9502 (probably m32a)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "./ATTOBASICV234_m32-16MHZ-uart_btldr.hex"
avrdude: writing flash (32768 bytes):

Writing | ################################################## | 100% 3.66s

avrdude: 32768 bytes of flash written
avrdude: verifying flash memory against ./ATTOBASICV234_m32-16MHZ-uart_btldr.hex:

Reading | ################################################## | 100% 2.90s

avrdude: 32768 bytes of flash verified

avrdude done.  Thank you.

[mcuee]

BTW, I can reproduce the issue with the default demo FW on my board. atmega32a_demo_muzi.hex.txt

[mcuee]

@dl8dtl and @MCUdude Since this is marked for AVRDUDE 7.1 milestone, how do we further diagnose the issue and then try to find a fix?

[mcuee]

Then I have another STK500v2 clone using a 8051 CPU (STC STC15W1K16S) which also claims to support HVSP/HVPP, and it does not have this issue. Looks like this one and the previous STK500v2 clone may not follow exactly the official STK500 FW.

And then the AVeRISP mkii clone and the STK500v2 clone using ATmega8535 (which also claims to support HVSP/HVPP) seem to follow the official FW.

So this somehow points for FW issues? Or there needs to be a workaround in avrdude?

[MCUdude]

Maybe @stefanrueger is able to figure out what's wrong here?

@mcuee I beleve there is an issue with the Avrdude implementation, and not necessary the official Atmel programmers. I can confirm that the ATTOBASICV234_m32-16MHZ-uart_btldr.hex file can sucessfully be written to an ATmega32 using an Atmel AVRISPmkII programmer though Microchip Studio 7 or using their CLI tool, atprogram.exe.

[stefanrueger]

It's a bootloader section write issue, so I wonder whether it's worthwhile playing with the lock bytes and the fuses: change the fuses for a larger, say 1024 bytes, boot section and see whether the verification error happens at 31 KiB rather than 31.5 KiB; that requires a non-0xff input test file up to the brim (maybe a test file with 16 K nop; or for variety, maybe some different effective nops such as mov rx,rx or even mov rx,ry to generate non-trivial bit patterns; just avoid a random file that risks port I/O). I know the BL lock bits normally are about allowing LPM/SPM in the selected bootloader area, but who knows whether that's the same for the ATmega32A? So, I'd ensure lock bits are all-permissive (though this could just be unnecessary superstition).

I also had a quick look at the write delays:

$ avrdude -p m32a/w
.wd_chip_erase 9.000 ms ATmega32A
.wd_eeprom 9.000 ms ATmega32A
.wd_flash 4.500 ms ATmega32A
.wd_lfuse 2.000 ms ATmega32A
.wd_hfuse 2.000 ms ATmega32A
.wd_lock 2.000 ms ATmega32A

That kinda looks suspicious. Normally, wd for fuses is the same as for flash.

Are the lock/fuse r/w commands in order? Perhaps check with avrdude -p m32a/s against data sheet. If that fails, I'd look at the write lock/fuse routines in stk500v2 (they may well not use the avrdude.conf values, so a careful check of the code might be in order).

If stk500v2.c reasons about where the bootloader sits that might well be a good place to check (I think @mcuee mentioned that already, that's a great shout).

I realise I am a bit vague here, but I neither have the programmers in question nor the part.

[MCUdude]

It's a bootloader section write issue, so I wonder whether it's worthwhile playing with the lock bytes and the fuses: change the fuses for a larger, say 1024 bytes, boot section and see whether the verification error happens at 31 KiB rather than 31.5 KiB

For reference, here is the same file written but the bootloader section size is set to 1024 bytes instead of 512:

$ ./avrdude -patmega32 -cavrispmkii -Ulfuse:w:0xbf:m -Uhfuse:w:0xc4:m -Uflash:w:/Users/hans/Downloads/ATTOBASICV234_m32-16MHZ-uart_btldr.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9502 (probably m32)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file 0xbf for lfuse
avrdude: writing 1 byte lfuse ...

Writing | ################################################## | 100% 0.01s

avrdude: 1 byte of lfuse written
avrdude: verifying lfuse memory against 0xbf

Reading | ################################################## | 100% 0.00s

avrdude: 1 byte of lfuse verified
avrdude: reading input file 0xc4 for hfuse
avrdude: writing 1 byte hfuse ...

Writing | ################################################## | 100% 0.01s

avrdude: 1 byte of hfuse written
avrdude: verifying hfuse memory against 0xc4

Reading | ################################################## | 100% 0.00s

avrdude: 1 byte of hfuse verified
avrdude: input file /Users/hans/Downloads/ATTOBASICV234_m32-16MHZ-uart_btldr.hex auto detected as Intel Hex
avrdude: reading input file /Users/hans/Downloads/ATTOBASICV234_m32-16MHZ-uart_btldr.hex for flash
         with 15206 bytes in 4 sections within [0, 0x7fff]
         using 120 pages and 154 pad bytes
avrdude: writing 15206 bytes flash ...

Writing | ################################################## | 100% 1.31s

avrdude: 15206 bytes of flash written
avrdude: verifying flash memory against /Users/hans/Downloads/ATTOBASICV234_m32-16MHZ-uart_btldr.hex

Reading | ################################################## | 100% 0.82s

avrdude: verification error, first mismatch at byte 0x7e00
         0xff != 0x0f
avrdude: verification error; content mismatch

avrdude done.  Thank you.

I also generated a 16kiB intel hex file with all zeros, and a 32kiB as well. Both of these files can be verified just fine...

$ srec_cat -generate 0x0000 0x3FFF -repeat_data 0x00 -o zeros16kib.hex -Intel
$ srec_cat -generate 0x0000 0x7FFF -repeat_data 0x00 -o zeros32kib.hex -Intel
$ ./avrdude -patmega32 -cavrispmkii -Ulfuse:w:0xbf:m -Uhfuse:w:0xc6:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9502 (probably m32)
avrdude: reading input file 0xbf for lfuse
avrdude: writing 1 byte lfuse ...

Writing | ################################################## | 100% 0.01s

avrdude: 1 byte of lfuse written
avrdude: verifying lfuse memory against 0xbf

Reading | ################################################## | 100% 0.00s

avrdude: 1 byte of lfuse verified
avrdude: reading input file 0xc6 for hfuse
avrdude: writing 1 byte hfuse ...

Writing | ################################################## | 100% 0.01s

avrdude: 1 byte of hfuse written
avrdude: verifying hfuse memory against 0xc6

Reading | ################################################## | 100% 0.00s

avrdude: 1 byte of hfuse verified

avrdude done.  Thank you.

$ ./avrdude -patmega32 -cavrispmkii -Uflash:w:zeros16kib.hex 

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9502 (probably m32)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: input file zeros16kib.hex auto detected as Intel Hex
avrdude: reading input file zeros16kib.hex for flash
avrdude: writing 16383 bytes flash ...

Writing | ################################################## | 100% 1.49s

avrdude: 16383 bytes of flash written
avrdude: verifying flash memory against zeros16kib.hex

Reading | ################################################## | 100% 0.94s

avrdude: 16383 bytes of flash verified

avrdude done.  Thank you.

$ ./avrdude -patmega32 -cavrispmkii -Uflash:w:zeros32kib.hex 

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9502 (probably m32)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: input file zeros32kib.hex auto detected as Intel Hex
avrdude: reading input file zeros32kib.hex for flash
avrdude: writing 32767 bytes flash ...

Writing | ################################################## | 100% 2.93s

avrdude: 32767 bytes of flash written
avrdude: verifying flash memory against zeros32kib.hex

Reading | ################################################## | 100% 1.85s

avrdude: 32767 bytes of flash verified

avrdude done.  Thank you.

That kinda looks suspicious. Normally, wd for fuses is the same as for flash.

This is the table from the ATmega32 datasheet. Chaning the timing in avrdude.conf to match the values specified in the datasheet didn't make any difference.

[stefanrueger]

Looks like a really hard nut. @MCUdude's test put paid to my theory about the boot section. Certain input files can be written certain input files cannot be written. The input file that does not work has 4 sections. Then @mcuee has found an input file with one section that also does not work. The OP seems to mention m328p can be written, the m32a cannot.

There were clear-cut errors of the m32 entry in avrdude.conf, but correcting these made no difference. I checked stk500v2.c and indeed these wd values are not used (only wd_chip_erase). Instead there are a couple of usleep(10000) with comments indicating the author thought that a hack (so hacking these up any further might make a change but that's not a satisfying solution even if it worked). Could it be that other vital m32 avrdude.conf entries used in stk500v2.c are wrong? I have no idea where to look up the correct values needed, and which ones are actually used, so I am out of my depth here. But I think giving the avrdude.conf entry a long hard check will at least have the side-effect of getting that correct and removing this as potential error source.

Also, what is the flash readout with :I of the correctly written flash and what's the one of the incorrectly written flash? The OP seemed to say errors started earlier at 0x7d00 (which might be in a "hole" that's not part of the verification), and could be where the write attempt for 0x7e00 has diffracted to. A diff of the two read-backs might give some insight?

[mcuee]

Indeed @MCUdude's testing results make this issue more difficult.

@stefanrueger Two guess from my side -- maybe not relevant at all but just my guess from going through all the issues in recent months. 1) Can it be similar to the strange issue of #455? Apparent the proposed fix does not seem to be right there but it did fix the issue.

2) Could it be related to https://github.com/avrdudes/avrdude/issues/1050?

[mcuee]

I can repeat the problem as well. Writing has the problem, reading is good. Interestingly only the location from 0x7E00 has the issues (26 bytes).

C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -qqp m32a -c avrispmkii 
-U lfuse:w:0xbf:m -U hfuse:w:0xc6:m && echo OK
OK

C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -qqp m32a -c avrispmkii 
-U .\atmega32a_demo_muzi.hex && echo OK
avrdude.exe: verification error, first mismatch at byte 0x7e00
             0xff != 0x0f
avrdude.exe: verification error; content mismatch

C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -qqp m32a -c avrispmkii 
-U flash:r:m32a_muzi_avrisp2_readback.hex:i && echo OK
OK

C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -qqp m32a -c usbasp 
-U flash:v:m32a_muzi_avrisp2_readback.hex:i && echo OK
OK

Original hex file.

:207D0000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF83
:207D2000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF63
:207D4000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF43
:207D6000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF23
:207D8000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF03
:207DA000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE3
:207DC000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC3
:207DE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA3
:207E00000F92CDB7DEB711248FE598E09EBF8DBF84B714BE982F9D7009F0D2D085E08EBDB2
:207E200082E08BB988E18AB986E880BD80E189B98EE0B2D0B89A24E080E39CEF54E041E019
:207E40009DBD8CBD58BF08B602FEFDCF38B3342738BBA8952150A1F700E010E053E0F52E39
:207E6000EE24E39465E0D62E71E1C72E8ED0813471F48BD0898394D08981823809F477C0AE
:207E8000813811F486E001C083E07BD077C0823411F484E103C0853419F485E089D06EC083
:207EA000853569F472D0A82EBB246FD0082F10E0102F00270A291B29000F111F5EC0863559
:207EC00021F484E075D080E0E0CF843609F039C05CD05BD0A82E59D0982EBA2C20E6622E91
:207EE000712C53D0F30181933F01BA94D1F758D0F5E49F1609F4FFCFF801F7BEE89507B6FB
:207F000000FCFDCFF8018A2DA0E6B0E04C9150E011962C91119730E0322F2227242B352B51
:207F200012960901E7BEE89511243296825071F7F801D7BEE89507B600FCFDCFC7BEE895A4
:207F40001DC0843769F421D020D0B82E1ED028D03801F30185913F0114D0BA94D1F70EC034
:207F6000853739F41DD08EE10CD085E90AD082E08CCF813511F488E00FD012D080E101D0C5
:207F800075CF5D9BFECF8CB908955F9BFECF5C9901C0A8958CB1089598E191BD81BD0895C0
:207FA000F4DF803219F088E0F7DFFFCF84E1E9CFCF93C82FEADFC150E9F7F2DFCF91089529
:207FC000282E80E0E9DFE0E0FF270994FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB4
:207FE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF020697
:00000001FF

What has been written:

:207D0000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF83
:207D2000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF63
:207D4000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF43
:207D6000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF23
:207D8000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF03
:207DA000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE3
:207DC000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC3
:207DE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA3
:207E0000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD2D085E08EBD2A
:207E200082E08BB988E18AB986E880BD80E189B98EE0B2D0B89A24E080E39CEF54E041E019
:207E40009DBD8CBD58BF08B602FEFDCF38B3342738BBA8952150A1F700E010E053E0F52E39
:207E6000EE24E39465E0D62E71E1C72E8ED0813471F48BD0898394D08981823809F477C0AE
:207E8000813811F486E001C083E07BD077C0823411F484E103C0853419F485E089D06EC083
:207EA000853569F472D0A82EBB246FD0082F10E0102F00270A291B29000F111F5EC0863559
:207EC00021F484E075D080E0E0CF843609F039C05CD05BD0A82E59D0982EBA2C20E6622E91
:207EE000712C53D0F30181933F01BA94D1F758D0F5E49F1609F4FFCFF801F7BEE89507B6FB
:207F000000FCFDCFF8018A2DA0E6B0E04C9150E011962C91119730E0322F2227242B352B51
:207F200012960901E7BEE89511243296825071F7F801D7BEE89507B600FCFDCFC7BEE895A4
:207F40001DC0843769F421D020D0B82E1ED028D03801F30185913F0114D0BA94D1F70EC034
:207F6000853739F41DD08EE10CD085E90AD082E08CCF813511F488E00FD012D080E101D0C5
:207F800075CF5D9BFECF8CB908955F9BFECF5C9901C0A8958CB1089598E191BD81BD0895C0
:207FA000F4DF803219F088E0F7DFFFCF84E1E9CFCF93C82FEADFC150E9F7F2DFCF91089529
:207FC000282E80E0E9DFE0E0FF270994FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB4
:207FE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF020697
:00000001FF

[mcuee]

And as per @MCUdude, I need to remove all the empty lines before it will work. Even single empty lines will cause problems.

C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -qqp m32a -c avrispmkii 
-U .\atmega32a_demo_muzi_mod.hex && echo OK
avrdude.exe: verification error, first mismatch at byte 0x7e00
             0xff != 0x0f
avrdude.exe: verification error; content mismatch

C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -qqp m32a -c avrispmkii 
-U .\atmega32a_demo_muzi_mod1.hex && echo OK
OK

$ diff atmega32a_demo_muzi_mod.hex atmega32a_demo_muzi_mod1.hex
37d36
< :20048000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7C

atmega32a_demo_muzi_mod.hex.txt atmega32a_demo_muzi_mod1.hex.txt

[mcuee]

Actually I can reproduce the issue with very simple hex file like the following. 26bytes will be written wrongly as 0xFF.

:020000040000FA
:20000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00
:20002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0
:20008000000000000000000000000000000000000000000000000000000000000000000060
:2000A000000000000000000000000000000000000000000000000000000000000000000040
:2000C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF40
:2000E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF20
:20010000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
:00000001FF

C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -qqp m32a -c avrispmkii 
-U .\simpletest1.hex && echo OK
avrdude.exe: verification error, first mismatch at byte 0x0080
             0xff != 0x00
avrdude.exe: verification error; content mismatch

C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -qqp m32a -c avrispmkii -t
avrdude> read flash 0x80 0x40
>>> read flash 0x80 0x40
0080  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0090  ff ff ff ff ff ff ff ff  ff ff 00 00 00 00 00 00  |................|
00a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

[MCUdude]

Actually I can reproduce the issue with very simple hex file like the following. 26bytes will be written wrongly as 0xFF.

The hex file you fail to be written to an ATmega8, ATmega16, or an ATmega32, but I can confirm that I can write it to an ATmega324P, ATmega328P, ATmega64, ATmega128, and ATmega1281.

ATmega32:

``` $ cat test-error.hex :020000040000FA :20000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00 :20002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0 :20008000000000000000000000000000000000000000000000000000000000000000000060 :2000A000000000000000000000000000000000000000000000000000000000000000000040 :2000C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF40 :2000E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF20 :20010000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF :00000001FF $ ./avrdude -patmega32 -cavrispmkii -Uflash:w:test-error.hex:i avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.00s avrdude: Device signature = 0x1e9502 (probably m32) avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: reading input file test-error.hex for flash with 128 bytes in 2 sections within [0, 0x11f] using 2 pages and 128 pad bytes, cutting off 96 trailing 0xff bytes avrdude: writing 128 bytes flash ... Writing | ######################### | 50% 0.00savrdude: stk500v2_command(): warning: Command timed out avrdude: stk500v2_paged_write: write command failed Writing | ################################################## | 100% 0.02s avrdude: 128 bytes of flash written avrdude: verifying flash memory against test-error.hex Reading | ################################################## | 100% 0.02s avrdude: 224 bytes of flash verified avrdude done. Thank you. $ echo "read flash 0 0x100" | ./avrdude -patmega32 -cavrispmkii -t avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.00s avrdude: Device signature = 0x1e9502 (probably m32) >>> read flash 0 0x100 Reading | ################################################## | 100% 0.01s 0000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 0020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 0030 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 0040 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 0050 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 0060 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 0070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 0080 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 0090 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 00a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 00b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 00c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 00d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 00e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 00f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| avrdude done. Thank you. ```

ATmega8:

``` $ ./avrdude -patmega8 -cavrispmkii -Uflash:w:test-error.hex:i avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.00s avrdude: Device signature = 0x1e9307 (probably m8) avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: reading input file test-error.hex for flash with 128 bytes in 2 sections within [0, 0x11f] using 2 pages and 0 pad bytes, cutting off 96 trailing 0xff bytes avrdude: writing 128 bytes flash ... Writing | ################################################## | 100% 0.00s avrdude: stk500v2_command(): warning: Command timed out avrdude: stk500v2_paged_write: write command failed avrdude: 128 bytes of flash written avrdude: verifying flash memory against test-error.hex Reading | ################################################## | 100% 0.01s avrdude: 224 bytes of flash verified avrdude done. Thank you. ```

ATmega16:

``` $ ./avrdude -patmega16 -cavrispmkii -Uflash:w:test-error.hex:i avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.00s avrdude: Device signature = 0x1e9403 (probably m16) avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: reading input file test-error.hex for flash with 128 bytes in 2 sections within [0, 0x11f] using 2 pages and 128 pad bytes, cutting off 96 trailing 0xff bytes avrdude: writing 128 bytes flash ... Writing | ######################### | 50% 0.00savrdude: stk500v2_command(): warning: Command timed out avrdude: stk500v2_paged_write: write command failed Writing | ################################################## | 100% 0.02s avrdude: 128 bytes of flash written avrdude: verifying flash memory against test-error.hex Reading | ################################################## | 100% 0.02s avrdude: 224 bytes of flash verified avrdude done. Thank you. ```

ATmega64:

``` $ ./avrdude -patmega64 -cavrispmkii -Uflash:w:test-error.hex:i avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.00s avrdude: Device signature = 0x1e9602 (probably m64) avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: reading input file test-error.hex for flash with 128 bytes in 2 sections within [0, 0x11f] using 1 page and 128 pad bytes, cutting off 96 trailing 0xff bytes avrdude: writing 128 bytes flash ... Writing | ################################################## | 100% 0.01s avrdude: 128 bytes of flash written avrdude: verifying flash memory against test-error.hex Reading | ################################################## | 100% 0.03s avrdude: 224 bytes of flash verified avrdude done. Thank you. ```

ATmega128:

``` $ ./avrdude -patmega128 -cavrispmkii -Uflash:w:test-error.hex:i avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.00s avrdude: Device signature = 0x1e9702 (probably m128) avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: reading input file test-error.hex for flash with 128 bytes in 2 sections within [0, 0x11f] using 1 page and 128 pad bytes, cutting off 96 trailing 0xff bytes avrdude: writing 128 bytes flash ... Writing | ################################################## | 100% 0.01s avrdude: 128 bytes of flash written avrdude: verifying flash memory against test-error.hex Reading | ################################################## | 100% 0.03s avrdude: 224 bytes of flash verified avrdude done. Thank you. ```

ATmega1281:

``` $ ./avrdude -patmega1281 -cavrispmkii -Uflash:w:test-error.hex:i avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.00s avrdude: Device signature = 0x1e9704 (probably m1281) avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: reading input file test-error.hex for flash with 128 bytes in 2 sections within [0, 0x11f] using 1 page and 128 pad bytes, cutting off 96 trailing 0xff bytes avrdude: writing 128 bytes flash ... Writing | ################################################## | 100% 0.01s avrdude: 128 bytes of flash written avrdude: verifying flash memory against test-error.hex Reading | ################################################## | 100% 0.03s avrdude: 224 bytes of flash verified avrdude done. Thank you. ```

For reference, I'm getting the same error when writing the ATTOBASICV234_m16-16MHZ-uart_btldr.hex file regardless of what the fuses are set to when writing to an ATmega32.

I'm not getting the error when writing the ATTOBASICV234_m16-16MHZ-uart_btldr.hex file to an ATmega324P or an ATmega328P. However, I do get an error when trying to write the /Users/hans/Downloads/ATTOBASICV234_m16-16MHZ-uart_btldr.hex file to an ATmega16, regardless of the fuse settings:

$ ./avrdude -patmega16 -cavrispmkii -Uflash:w:/Users/hans/Downloads/ATTOBASICV234_m16-16MHZ-uart_btldr.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9403 (probably m16)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: input file /Users/hans/Downloads/ATTOBASICV234_m16-16MHZ-uart_btldr.hex auto detected as Intel Hex
avrdude: reading input file /Users/hans/Downloads/ATTOBASICV234_m16-16MHZ-uart_btldr.hex for flash
         with 15204 bytes in 4 sections within [0, 0x3fff]
         using 120 pages and 156 pad bytes
avrdude: writing 15204 bytes flash ...

Writing | ################################################## | 100% 1.28s

avrdude: 15204 bytes of flash written
avrdude: verifying flash memory against /Users/hans/Downloads/ATTOBASICV234_m16-16MHZ-uart_btldr.hex

Reading | ################################################## | 100% 0.82s

avrdude: verification error, first mismatch at byte 0x3e00
         0xff != 0x0f
avrdude: verification error; content mismatch

avrdude done.  Thank you.

[MCUdude]

Just to complete the test:

ATmega8535 (fails):

``` $ ./avrdude -patmega8535 -cavrispmkii -Uflash:w:test-error.hex:i avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.00s avrdude: Device signature = 0x1e9308 (probably m8535) avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: reading input file test-error.hex for flash with 128 bytes in 2 sections within [0, 0x11f] using 2 pages and 0 pad bytes, cutting off 96 trailing 0xff bytes avrdude: writing 128 bytes flash ... Writing | ################################################## | 100% 0.00s avrdude: stk500v2_command(): warning: Command timed out avrdude: stk500v2_paged_write: write command failed avrdude: 128 bytes of flash written avrdude: verifying flash memory against test-error.hex Reading | ################################################## | 100% 0.02s avrdude: 224 bytes of flash verified avrdude done. Thank you. ```

ATmega8515 (fails):

``` $ ./avrdude -patmega8515 -cavrispmkii -Uflash:w:test-error.hex:i avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.00s avrdude: Device signature = 0x1e9306 (probably m8515) avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: reading input file test-error.hex for flash with 128 bytes in 2 sections within [0, 0x11f] using 2 pages and 0 pad bytes, cutting off 96 trailing 0xff bytes avrdude: writing 128 bytes flash ... Writing | ################################################## | 100% 0.00s avrdude: stk500v2_command(): warning: Command timed out avrdude: stk500v2_paged_write: write command failed avrdude: 128 bytes of flash written avrdude: verifying flash memory against test-error.hex Reading | ################################################## | 100% 0.01s avrdude: 224 bytes of flash verified avrdude done. Thank you. ```

ATmega162 (succeeds):

``` $ ./avrdude -patmega162 -cavrispmkii -Uflash:w:test-error.hex:i avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.00s avrdude: Device signature = 0x1e9404 (probably m162) avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: reading input file test-error.hex for flash with 128 bytes in 2 sections within [0, 0x11f] using 2 pages and 128 pad bytes, cutting off 96 trailing 0xff bytes avrdude: writing 128 bytes flash ... Writing | ################################################## | 100% 0.01s avrdude: 128 bytes of flash written avrdude: verifying flash memory against test-error.hex Reading | ################################################## | 100% 0.03s avrdude: 224 bytes of flash verified avrdude done. Thank you. ```

[mcuee]

@MCUdude

I see some warnings in your run log.

avrdude: stk500v2_command(): warning: Command timed out
avrdude: stk500v2_paged_write: write command failed

Interestingly I do not see such warnings with ATmega32A.

C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -p m32a -c avrispmkii  -U .\simpletest1.hex -v

avrdude.exe: Version 7.0-20220804 (5f5002e)
             Copyright (c) Brian Dean, http://www.bdmicro.com/
             Copyright (c) Joerg Wunsch

             System wide configuration file is "C:/work/avr/avrdude_test/avrdude_bin/avrdude.conf"

             Using Port                    : usb
             Using Programmer              : avrispmkii
avrdude.exe: usbdev_open(): Found AVRISP mkII, serno: 001D2C990079
             AVR Part                      : ATmega32A
             Chip Erase delay              : 9000 us
             PAGEL                         : PD7
             BS2                           : PA0
             RESET disposition             : dedicated
             RETRY pulse                   : SCK
             Serial program mode           : yes
             Parallel program mode         : yes
             Timeout                       : 200
             StabDelay                     : 100
             CmdexeDelay                   : 25
             SyncLoops                     : 32
             PollIndex                     : 3
             PollValue                     : 0x53
             Memory Detail                 :

                                               Block Poll               Page                       Polled
               Memory Type Alias    Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
               ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
               eeprom                  4    10    64    0 no       1024    4      0  9000  9000 0xff 0xff
               flash                  33     6    64    0 yes     32768  128    256  4500  4500 0xff 0xff
               lfuse                   0     0     0    0 no          1    1      0  2000  2000 0x00 0x00
               hfuse                   0     0     0    0 no          1    1      0  2000  2000 0x00 0x00
               lock                    0     0     0    0 no          1    1      0  2000  2000 0x00 0x00
               signature               0     0     0    0 no          3    1      0     0     0 0x00 0x00
               calibration             0     0     0    0 no          4    1      0     0     0 0x00 0x00

             Programmer Type : STK500V2
             Description     : Atmel AVR ISP mkII
             Programmer Model: AVRISP mkII
             Hardware Version: 1
             Firmware Version Master : 1.24
             Vtarget         : 4.9 V
             SCK period      : 4.00 us

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude.exe: Device signature = 0x1e9502 (probably m32a)
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
             To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: input file .\simpletest1.hex auto detected as Intel Hex
avrdude.exe: reading input file .\simpletest1.hex for flash
             with 128 bytes in 2 sections within [0, 0x11f]
             using 2 pages and 128 pad bytes, cutting off 96 trailing 0xff bytes
avrdude.exe: writing 128 bytes flash ...

Writing | ################################################## | 100% 0.02s

avrdude.exe: 128 bytes of flash written
avrdude.exe: verifying flash memory against .\simpletest1.hex

Reading | ################################################## | 100% 0.08s

avrdude.exe: verification error, first mismatch at byte 0x0080
             0xff != 0x00
avrdude.exe: verification error; content mismatch

avrdude.exe done.  Thank you.

[mcuee]

Looks like the issue has been there for long time. I switched the driver from Microchip official WinUSB based driver to libusbk.sys (you can also use libusb0.sys) to use old release version of avrdude. http://download.savannah.gnu.org/releases/avrdude/

FYI: 6.0.1 was released on 18-Sep-2013.

C:\work\avr\avrdude_test\release\avrdude-6.0.1-mingw32> .\avrdude -p m32 -c avrispmkii 
 -P usb -U .\simpletest1.hex

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude.exe: Device signature = 0x1e9502
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
             To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file ".\simpletest1.hex"
avrdude.exe: input file .\simpletest1.hex auto detected as Intel Hex
avrdude.exe: writing flash (192 bytes):

Writing | ################################################## | 100% 0.03s

avrdude.exe: 192 bytes of flash written
avrdude.exe: verifying flash memory against .\simpletest1.hex:
avrdude.exe: load data flash data from input file .\simpletest1.hex:
avrdude.exe: input file .\simpletest1.hex auto detected as Intel Hex
avrdude.exe: input file .\simpletest1.hex contains 192 bytes
avrdude.exe: reading on-chip flash data:

Reading | ################################################## | 100% 0.08s

avrdude.exe: verifying ...
avrdude.exe: verification error, first mismatch at byte 0x0080
             0xff != 0x00
avrdude.exe: verification error; content mismatch

avrdude.exe: safemode: Fuses OK (H:FF, E:C6, L:BF)

avrdude.exe done.  Thank you.

[mcuee]

But the older version seems to be okay. avrdude-5.11-Patch7610-win32 was released on 31-Aug-2011.

C:\work\avr\avrdude_test\release\avrdude-5.11-Patch7610-win32> .\avrdude -p m32 -c avrispmkii  
-P usb -U .\simpletest1.hex

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude.exe: Device signature = 0x1e9502
avrdude.exe: NOTE: FLASH memory has been specified, an erase cycle will be performed
             To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file ".\simpletest1.hex"
avrdude.exe: input file .\simpletest1.hex auto detected as Intel Hex
avrdude.exe: writing flash (192 bytes):

Writing | ################################################## | 100% 0.02s

avrdude.exe: 192 bytes of flash written
avrdude.exe: verifying flash memory against .\simpletest1.hex:
avrdude.exe: load data flash data from input file .\simpletest1.hex:
avrdude.exe: input file .\simpletest1.hex auto detected as Intel Hex
avrdude.exe: input file .\simpletest1.hex contains 192 bytes
avrdude.exe: reading on-chip flash data:

Reading | ################################################## | 100% 0.03s

avrdude.exe: verifying ...
avrdude.exe: 192 bytes of flash verified

avrdude.exe: safemode: Fuses OK

avrdude.exe done.  Thank you.

C:\work\avr\avrdude_test\release\avrdude-5.11-Patch7610-win32> .\avrdude -qqp m32 -c avrispmkii 
 -P usb -U .\atmega32a_demo_muzi.hex && echo OK
OK

C:\work\avr\avrdude_test\release\avrdude-5.11-Patch7610-win32> .\avrdude -qqp m32 -c avrispmkii 
 -P usb -U .\ATTOBASICV234_m32-16MHZ-uart_btldr.hex && echo OK
OK

[MCUdude]

But the older version seems to be okay.

It would be interesting if we could trace it down to a single commit. However, I have no experience with SVN, and I'm having a hard time even finding the old source code that is (was?) hosted over at Savannah.

[mcuee]

But the older version seems to be okay.

It would be interesting if we could trace it down to a single commit. However, I have no experience with SVN, and I'm having a hard time even finding the old source code that is (was?) hosted over at Savannah.

@MCUdude No need to go to SVN. This git repo has all the histories.

Example for stk500v2.c (hopefully it is because of stk500v2.c but it might be other changes). https://github.com/avrdudes/avrdude/commits/5633a6d88ab199b68ba68d53717efc21c0cc5868/stk500v2.c?browsing_rename_history=true&new_path=src/stk500v2.c&original_branch=main

[MCUdude]

@mcuee I did have a look at the changes done to stk500v2.c from 09/2011 to 09/2013 (changes from 5.11 to 6.0.1) but I couldn't really find anything that could cause this. Either I didn't search well enough, or the issue may be somewhere else. I don't know really.

[mcuee]

@mcuee I did have a look at the changes done to stk500v2.c from 09/2011 to 09/2013 (changes from 5.11 to 6.0.1) but I couldn't really find anything that could cause this. Either I didn't search well enough, or the issue may be somewhere else. I don't know really.

Indeed it could be other files as well but that can be strange. Example: the following issue is somewhat related to fileio.c but it could be incorrect fix.

• https://github.com/avrdudes/avrdude/issues/455

fileio.c change history. https://github.com/avrdudes/avrdude/commits/5633a6d88ab199b68ba68d53717efc21c0cc5868/fileio.c?browsing_rename_history=true&new_path=src/fileio.c&original_branch=main

BTW, I have also checked avrdude.conf.in change history and I did not see anything there either.

[mcuee]

I have futher narrow down that this commit is already bad (20-Nov-2012). It is faster to do build under Linux so I am using Ubuntu 20.04 (dual boot with Windows 11). https://github.com/avrdudes/avrdude/tree/147137a218a41e672cc301659cc5782afd1a615a

The following commit on 19 Apr 2012 is also bad. https://github.com/avrdudes/avrdude/tree/f4db29d983c1864a65c33875672a3e8b6596a15b

The following commit on 15 Sept 2011 is also bad. c3d58bc

The following is good on 13 Sept 2011. https://github.com/avrdudes/avrdude/commit/0926a2cbd7bdf982073cad49977841f263326779

5.11.1 release is also okay (16 Sept 2011) https://github.com/avrdudes/avrdude/releases/tag/v5.11.1

Finally zoom down to this mega commit which seems to be the issue -- 15 Sept 2011. https://github.com/avrdudes/avrdude/commit/d742827da15a8e6165d956735ec48f1acff575e3

[mcuee]

Just want to document the process I used to zoom down to the paticular commits. I am not good at git so I do not know how to use git bisect but I kind of follow the principal.

 2025  git clone https://github.com/avrdudes/avrdude.git
 2026  cd avrdude
 2027  ls
 2028  git checkout 147137a
 2029  git log
 2030  ls
 2031  ./bootstrap 
 2032  ./configure 
 2033  make
 2034  sudo ./avrdude -C ./avrdude.conf -p m32 -c avrispmkii -P usb -U ../simpletest1.hex
 2035  ls
 2036  rm INSTALL 
 2037  git checkout main
 2038  git pull
 2039  git diff
 2040  git checkout f4db29d
 2041  ./bootstrap 
 2042  ./configure 
 2043  make
 2044  sudo ./avrdude -C ./avrdude.conf -p m32 -c avrispmkii -P usb -U ../simpletest1.hex
 2045  rm INSTALL 
 2046  git checkout main
 2047  git checkout c3d58bc
 2048  ./bootstrap 
 2049  ./configure 
 2050  make
 2051  sudo ./avrdude -C ./avrdude.conf -p m32 -c avrispmkii -P usb -U ../simpletest1.hex
 2052  cd ..
 2053  ls
 2054  mv ~/Downloads/avrdude-5.11.1.tar.gz .
 2055  tar zxvf avrdude-5.11.1.tar.gz 
 2056  cd avrdude-5.11.1/
 2057  ls
 2058  cd avrdude/
 2059  ls
 2060  ./bootstrap 
 2061  ./configure 
 2062  make
 2063  sudo ./avrdude -C ./avrdude.conf -p m32 -c avrispmkii -P usb -U ../simpletest1.hex
 2064  sudo ./avrdude -C ./avrdude.conf -p m32 -c avrispmkii -P usb -U ../../simpletest1.hex
 2065  cd ..
 2066  cd avrdude
 2067  ls
 2068  rm INSTALL 
 2069  git checkout main
 2070  git checkout 0926a2c
 2071  ./bootstrap 
 2072  ./configure 
 2073  make
 2074  sudo ./avrdude -C ./avrdude.conf -p m32 -c avrispmkii -P usb -U ../simpletest1.hex
 2075  rm INSTALL 
 2076  git checkout main
 2077  git checkout d742827
 2078  ./bootstrap 
 2079  ./configure 
 2080  make
 2081  sudo ./avrdude -C ./avrdude.conf -p m32 -c avrispmkii -P usb -U ../simpletest1.hex
 2082  git log
 2083  ls
 2084  rm INSTALL 
 2085  git checkout main

[mcuee]

@dl8dtl and @stefanrueger and @MCUdude Hopefuly now you can look at the paticual mega commit to see where is the issue. Thanks. https://github.com/avrdudes/avrdude/commit/d742827da15a8e6165d956735ec48f1acff575e3

[MCUdude]

Great work @mcuee! Sadly, it's a huge commit, and I don't really know what to look for. But now tracking it down to a single commit is still very helpful 👏

[mcuee]

Great work @mcuee! Sadly, it's a huge commit, and I don't really know what to look for. But now tracking it down to a single commit is still very helpful clap

Ineed it is a mega commit. Hopefully @dl8dtl or @stefanrueger can look at the commit and see where is the issue.

[mcuee]

BTW, the mega commit touched quite some programmers and USBASP is one of them. It also got the same issue at tthat time. But it must have been fixed since git main version does work. [Update: 6.0.1 release is already good for usbasp].

mcuee@UbuntuSwift3:~/build/avr/avrdude_release/avrdude$ ./avrdude -C ./avrdude.conf -p m32 
-c usbasp -P usb -U ../simpletest1.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9502
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "../simpletest1.hex"
avrdude: input file ../simpletest1.hex auto detected as Intel Hex
avrdude: writing flash (192 bytes):

Writing | ################################################## | 100% 0.06s

avrdude: 192 bytes of flash written
avrdude: verifying flash memory against ../simpletest1.hex:
avrdude: load data flash data from input file ../simpletest1.hex:
avrdude: input file ../simpletest1.hex auto detected as Intel Hex
avrdude: input file ../simpletest1.hex contains 192 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.06s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0080
         0xff != 0x00
avrdude: verification error; content mismatch

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

mcuee@UbuntuSwift3:~/build/avr/avrdude_release/avrdude-6.0.1$ ./avrdude -C ./avrdude.conf -qqp m32 
-c usbasp -P usb -U ../simpletest1.hex && echo OK
OK

mcuee@UbuntuSwift3:~/build/avr/avrdude_release/avrdude-6.0.1$ ./avrdude -C ./avrdude.conf -qqp m32 
-c usbasp -P usb -U ../simpletest1.hex && echo OK
OK

[mcuee]

For usbasp, it was fixed by the following commit. https://github.com/avrdudes/avrdude/commit/0b3feb71b81e9f12a21994526897f6d8e4446db6

It is actually the next commit aftet the mega commit for usbasp.c. https://github.com/avrdudes/avrdude/commits/5633a6d88ab199b68ba68d53717efc21c0cc5868/usbasp.c?browsing_rename_history=true&new_path=src/usbasp.c&original_branch=main

[mcuee]

For USBtinyISP, the mega commit also got the same issue (along with some other issues). But then it is fixed by similar commits as the above-mentioned usbasp fix. https://github.com/avrdudes/avrdude/commit/bde3c841e5c9563ab696e9df9c82f5a64ac36a42

mcuee@UbuntuSwift3:~/build/avr/avrdude_release/bin_archive_git$ ./avrdude_d742827 
-C ./avrdude_d742827.conf -qqp m32 -c usbtiny -P usb -U ../simpletest1.hex && echo OK

avrdude_d742827: error: usbtiny_send: Input/output error (expected 0, got -5)

avrdude_d742827: error: usbtiny_receive: Input/output error (expected 128, got -5)

avrdude_d742827: error: usbtiny_receive: Input/output error (expected 0, got -5)

avrdude_d742827: error: usbtiny_receive: Input/output error (expected 128, got -5)
avrdude_d742827: verification error, first mismatch at byte 0x0080
                 0xff != 0x00
avrdude_d742827: verification error; content mismatch

avrdude_d742827: error: usbtiny_receive: Input/output error (expected 4, got -5)

avrdude_d742827: error: usbtiny_receive: Input/output error (expected 4, got -5)

avrdude_d742827: error: usbtiny_receive: Input/output error (expected 4, got -5)

avrdude_d742827: error: usbtiny_receive: Input/output error (expected 4, got -5)

avrdude_d742827: error: usbtiny_receive: Input/output error (expected 4, got -5)

avrdude_d742827: error: usbtiny_receive: Input/output error (expected 4, got -5)
avrdude_d742827: safemode: lfuse changed! Was bf, and is now 0
Would you like this fuse to be changed back? [y/n] ^C

mcuee@UbuntuSwift3:~/build/avr/avrdude_release/bin_archive_git$ ./avrdude_bde3c84 
-C ./avrdude_bde3c84.conf -qqp m32 -c usbtiny -P usb -U ../simpletest1.hex && echo OK
OK

[mcuee]

For the original STK500 v1 FW (origninal STK500 V1 FW), there is no issue with the mega commit and latest git main.

mcuee@UbuntuSwift3:~/build/avr/avrdude_release/bin_archive_git$ ./avrdude_d742827 
-C ./avrdude_d742827.conf -c stk500v1 -P /dev/ttyUSB0 -qqp m32 -D -U ../simpletest1.hex && echo OK
OK

mcuee@UbuntuSwift3:~/build/avr/avrdude_release/bin_archive_git$ avrdude -qqp m32 
-c stk500v1 -P /dev/ttyUSB0 -U ../simpletest1.hex && echo OK
OK

The stk500v1 bootloader seems to be fine as well.

mcuee@UbuntuSwift3:~/build/avr/avrdude_release/bin_archive_git$ ./avrdude_d742827 
-C ./avrdude_d742827.conf -c arduino -P /dev/ttyUSB0 -qqp m32 -D -U ../simpletest1.hex && echo OK
OK

mcuee@UbuntuSwift3:~/build/avr/avrdude_release/bin_archive_git$ avrdude -c arduino -P /dev/ttyUSB0
 -qqp m32 -D -U ../simpletest1.hex && echo OK
OK

[mcuee]

For JTAg ICE mki, there was no issue with 5.11.1 release, but then it has issues with the mage commit and release 6.0.1/6.1/6.2.

Release 6.3 onwards works fine. And there is no issues with latest git main.

mcuee@UbuntuSwift3:~/build/avr/avrdude_release/bin_archive_git$ ./avrdude_d742827
 -C ./avrdude_d742827.conf -qqp m32 -c jtag1 -P /dev/ttyUSB0 -U ../simpletest1.hex && echo OK
avrdude_d742827: jtagmkI_paged_load(): timeout/error communicating with programmer (resp �)
avrdude_d742827: jtagmkI_paged_load(): timeout/error communicating with programmer (resp �)
avrdude_d742827: jtagmkI_paged_load(): timeout/error communicating with programmer (resp �)
avrdude_d742827: jtagmkI_paged_load(): timeout/error communicating with programmer (resp �)
avrdude_d742827: jtagmkI_paged_load(): timeout/error communicating with programmer (resp �)
avrdude_d742827: verification error, first mismatch at byte 0x0080
                 0xff != 0x00
avrdude_d742827: verification error; content mismatch

mcuee@UbuntuSwift3:~/build/avr/avrdude_release/bin_archive_git$ avrdude -qqp m32 -c jtag1
 -P /dev/ttyUSB0 -U ../simpletest1.hex && echo OK
OK

I belive the following commit addressed the issue but it has other problems. https://github.com/avrdudes/avrdude/commit/25829f2c5e961154bb5f9f4fff7c411b30da4058

mcuee@UbuntuSwift3:~/build/avr/avrdude_release/avrdude-6.2$ ./avrdude -C ./avrdude.conf 
-qqp m32 -c jtagmki -P /dev/ttyUSB0 -U ../simpletest1.hex && echo OK
Floating point exception (core dumped)

[mcuee]

The mega commit also affects avr109 bootloader, avr910, avrftdi and jtagmkii. I will see if I can test avr109 and avrftdi with my ATmega32 later.

@dl8dtl and @MCUdude Not so sure if you can help testing the avr910 and jtagmkii. Most likely jtagmkii will have the same issue as it is similar to AVR Dragon. I am still waiting for my AVR910 programmer to come.

[mcuee]

I can confirm that avr109 is okay for the git main. The mega commit also does not seem to affect avr109.

mcuee@UbuntuSwift3:~/build/avr/avrdude_release/bin_archive_git$ avrdude -qqp m32a 
-c avr109 -P /dev/ttyUSB0 -b 115200 -D -U ../simpletest1.hex && echo OK
Connecting to programmer: .
Found programmer: Id = "AVRBOOT"; type = S
    Software Version = 1.5; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.

Programmer supports the following devices:
    Device code: 0x7f

OK

mcuee@UbuntuSwift3:~/build/avr/avrdude_release/bin_archive_git$ ./avrdude_d742827 
-C ./avrdude_d742827.conf -qqp m32 -c avr109 -P /dev/ttyUSB0 -b 115200
 -D -U ../simpletest1.hex && echo OK
Connecting to programmer: .
Found programmer: Id = "AVRBOOT"; type = S
    Software Version = 1.5; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.

Programmer supports the following devices:
    Device code: 0x7f

OK

[mcuee]

For avrftdii, git main is having issues with OP's test hex file but not the simple test hex files. The issue with OP's test hex may be different from this one as well.

It is okay with the simple test hex files.

mcuee@UbuntuSwift3:~/build/avr/avrdude_release/avrdude-7.0$ avrdude -p m32 -c jtagkey 
-U ../simpletest1.hex 

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9502 (probably m32)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: input file ../simpletest1.hex auto detected as Intel Hex
avrdude: reading input file ../simpletest1.hex for flash
         with 128 bytes in 2 sections within [0, 0x11f]
         using 2 pages and 128 pad bytes, cutting off 96 trailing 0xff bytes
avrdude: writing 128 bytes flash ...

Writing | ################################################## | 100% 0.04s

avrdude: 128 bytes of flash written
avrdude: verifying flash memory against ../simpletest1.hex

Reading | ################################################## | 100% 0.08s

avrdude: 224 bytes of flash verified

avrdude done.  Thank you.

It is also okay with my demo hex file.

mcuee@UbuntuSwift3:~/build/avr/avrdude_release/avrdude-7.0$ avrdude -qqp m32 -c jtagkey
 -U ../atmega32a_demo_muzi.hex && echo OK
OK

It has the mismatch issue with the OP's test hex file but seems to be a bit different.

mcuee@UbuntuSwift3:~/build/avr/avrdude_release/avrdude-7.0$ ./avrdude -C ./avrdude.conf -qqp m32
 -c jtagkey -U ../ATTOBASICV234_m32-16MHZ-uart_btldr.hex && echo OK
avrdude: verification error, first mismatch at byte 0x0000
         0xff != 0x0c
avrdude: verification error; content mismatch

I can not test the mega commit or nearby releases like 5.11.1 as they all have issues with libftdi0. And 5.10 release does not support avrftdi.

mcuee@UbuntuSwift3:~/build/avr/avrdude_release/avrdude-5.11.1/avrdude$ ./avrdude -C ./avrdude.conf -qqp m32 
-c jtagkey -U ../simpletest1.hex
*** stack smashing detected ***: terminated
Aborted (core dumped)

But I can confirm that 6.0.1 release has the same issue as reported here. Same for 6.1, 6.2 and 6.3.

mcuee@UbuntuSwift3:~/build/avr/avrdude_release/avrdude-6.0.1$ ./avrdude -C ./avrdude.conf -qqp m32 
-c jtagkey -U ../simpletest1.hex && echo OK
avrdude: verification error, first mismatch at byte 0x0080
         0xff != 0x00
avrdude: verification error; content mismatch

6.4 and 7.0 release seem to be the same as git main. All have prolems with the OP's hex file but tthe mismatch happens at the first byte,

mcuee@UbuntuSwift3:~/build/avr/avrdude_release/avrdude-7.0$ ./avrdude -C ./avrdude.conf -qqp m32
 -c jtagkey -U ../simpletest1.hex && echo OK
OK

mcuee@UbuntuSwift3:~/build/avr/avrdude_release/avrdude-7.0$ ./avrdude -C ./avrdude.conf -qqp m32
 -c jtagkey -U ../atmega32a_demo_muzi.hex && echo OK
OK

cuee@UbuntuSwift3:~/build/avr/avrdude_release/avrdude-7.0$ ./avrdude -C ./avrdude.conf -qqp m32
 -c jtagkey -U ../ATTOBASICV234_m32-16MHZ-uart_btldr.hex && echo OK
avrdude: verification error, first mismatch at byte 0x0000
         0xff != 0x0c
avrdude: verification error; content mismatch

[mcuee]

Looking at the avrftdi.c history, there are not many changes after the 6.2 release on 17 Feb 2016. https://github.com/avrdudes/avrdude/commits/5633a6d88ab199b68ba68d53717efc21c0cc5868/avrftdi.c?browsing_rename_history=true&new_path=src/avrftdi.c&original_branch=mainl

Most likely the fix in this commit helps the things but may not sort all the issues. https://github.com/avrdudes/avrdude/commit/eb461f706f35611d8d968bc21197dae3a8f64c78

The above commit somehow does not work for me though.

mcuee@UbuntuSwift3:~/build/avr/avrdude_release/bin_archive_git$ ./avrdude_eb461f7 
-C ./avrdude_eb461f7.conf -c jtagkey -qqp m32 -U ../simpletest1.hex 
avrdude_eb461f7: error at ./avrdude_eb461f7.conf:4422: can't find parent part
avrdude_eb461f7: error reading system wide configuration file "./avrdude_eb461f7.conf"

Following commit fixed the above conf file issue. And indeed it has the same behaviour as the 6.4/7.0 release and git main. 1b3afa4

[mcuee]

Just a summary of this issue. The root cause of the issue is the mega commit https://github.com/avrdudes/avrdude/commit/d742827da15a8e6165d956735ec48f1acff575e3 on 15 Seot 2011.

The mega commit affects multiple programmers but some of them (like jtagmki, usbasp and usbtiny) have since fixed the issue. It does not seem to affect avr109 bootloader and STK500v1.

1) To be tested: avr910 programmer (Done on 21-August-2022, no issue) 2) Confirmed and need to be fixed: stk500v2, jtagmkii (AVR Dragon and AVR JTAGICE mkii) 3) For avrftdi, the particular issue may have been fixed but there is still another issue not related to this issue. (Tested on 21-August 2022, #1074 will fix this remaining issue)