[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 "<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?

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