avrdude [bug #48261] ATmega32A, AVR DRAGON ISP programming, verification error

Johnny Quest [email protected] 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

Dec 10 '21 23:12 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

Dec 10 '21 23:12 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

Dec 10 '21 23:12 avrs-admin

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.

May 30 '22 09:05 mcuee

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:

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.

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.

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.

Solution is simple: don't touch the Dragon in that area. And how to accomplish that ? Give it a proper housing.

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.

Add a buffer that can withstand that abuse.

May 30 '22 10:05 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 "<stdout>"
0x8f
avrdude: reading hfuse memory:

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

avrdude: writing output file "<stdout>"
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?

May 30 '22 17:05 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

May 30 '22 18:05 MCUdude

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.

Jun 03 '22 12:06 mcuee

@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?

Jun 08 '22 05:06 MCUdude

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

Jun 08 '22 06:06 dl8dtl

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.

Jun 15 '22 13:06 mcuee

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

Jun 16 '22 14:06 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.

Jul 11 '22 12:07 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.

Jul 11 '22 12:07 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.

Jul 11 '22 13:07 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.

Jul 11 '22 13:07 mcuee

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

Jul 11 '22 13:07 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?

Jul 28 '22 00:07 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?

Jul 31 '22 14:07 mcuee

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.

Aug 03 '22 18:08 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; 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.

Aug 04 '22 16:08 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

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.

Aug 04 '22 21:08 MCUdude

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?

Aug 04 '22 22:08 stefanrueger

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.

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.
Could it be related to https://github.com/avrdudes/avrdude/issues/1050?

Aug 05 '22 02:08 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

Aug 05 '22 03:08 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

Aug 05 '22 04:08 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  |................|

Aug 05 '22 05:08 mcuee

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.

Aug 05 '22 05:08 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.

Aug 05 '22 06:08 MCUdude

@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.

Aug 05 '22 06:08 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.

Aug 05 '22 06:08 mcuee

avrdude avrdude copied to clipboard

[bug #48261] ATmega32A, AVR DRAGON ISP programming, verification error

avrdude
avrdude copied to clipboard