[bug #48261] STK500V2 ISP problem with ATmega8/8515/8535, ATmega16 and ATmega32 #425
Comments
|
Scott Vitale Hello: avrdude -u -p m16 -c dragon_isp -B 500kHz -U flash:w:ATTOBASICV234_m16-16MHZ-uart_btldr.hex "avrdude: verifying ... I will upload the original file for this one as well. Peace and blessings, |
|
Scott Vitale 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 |
|
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. |
|
I'll give it a try later today with an ATmega32. The dragon is indeed very flakey. Some information here:
|
|
I can confirm that there's something going on with the dragon. Here are the ATmega32's fuse settings: Here is OPs hex file written with an AVR dragon (fails): Dragon non-verbose output: 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. Here's OPs hex file written with a USBasp (succeeds): To my surprise, the AVRISPmkII also fails: @dl8dtl do you have any idea why the Dragon and the AVRISPmkII fail? |
|
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
|
|
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. |
|
@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? |
|
Sounds to me like a bug in the stk500v2 code (which is used for Dragon, STK500, AVRISPmkII and so on). |
|
Not so sure if it is to do with the |
|
I do not have the ATmega32A, not so sure if I can test with ATmega328P or not. |
|
I just got an ATmega32A board running MightyCore. Tested with an AVRISP mkii clone, I can reproduce the issue. However, I can not reproduce the issue with an STK500v2 clone. That is strange. |
@MCUdude |
|
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). |
|
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. |
|
BTW, I can reproduce the issue with the default demo FW on my board. |
So this somehow points for FW issues? Or there needs to be a workaround in avrdude? |
|
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 |
|
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 I also had a quick look at the write delays: 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 If I realise I am a bit vague here, but I neither have the programmers in question nor the part. |
For reference, here is the same file written but the bootloader section size is set to 1024 bytes instead of 512: 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...
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. |
|
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 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 |
|
Indeed @MCUdude's testing results make this issue more difficult. @stefanrueger
|
|
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). Original hex file. What has been written: |
|
And as per @MCUdude, I need to remove all the empty lines before it will work. Even single empty lines will cause problems. atmega32a_demo_muzi_mod.hex.txt |
|
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: ATmega8: ATmega16: ATmega64: ATmega128: ATmega1281: For reference, I'm getting the same error when writing the I'm not getting the error when writing the |
|
Just to complete the test: ATmega8535 (fails): ATmega8515 (fails): ATmega162 (succeeds): |
|
@MCUdude should be changed to |
mcuee
changed the title
|
Before we drop it from the 7.1 release, I'd like to play around with the stk500v2.c file. After all, the mega commit (d742827) didn't change that much in stk500v2.c anyways. I can't promise anything, but it's worth a shot. @mcuee, can you test if this applies to STK500 HVPP programming as well? STK500V2 uses a different writing routine than the regular ISP. I'm currently at work, so I can't test this at the moment. Another thing. can you check if verification works as it should? In stk500v2.c, both |
|
I upgraded my STK500 ATmega8535 Clone with V2 FW from V1 FW using usbasp. It seems to me
I also tested the orginal reported hex file and the conclusion is the same. |
I believe writing is the issue and not reading, based on my previous testing. I just created a test hex file (big size but similar to my simple test hex file) and write the flashing using usbasp. |
Hopefully the above test results give you some clues to fix the issue.
|
|
The commit in question introduced memory tags to describe holes input data. Could it be that the physical programmer FW somehow autoincrements for those parts in a different way than stk500v2? So any hole in the data (a page_size worth of 0xFF) could throw a spanner in the works. This hole hypothesis can be tested as follows: modify stk500v2.c to always (unconditionally) use stk500v2_loadaddr() for every page written/read irrespective of whether autoincrement might render that unnecessary. If that fixes the problem, then the question remains why for those parts only (as m328p works?). Maybe it is one of the myriad STK500v2 parameters that are different from m328p to m32 avrdude -pm32/S >/tmp/m32; avrdude -pm328p/S >/tmp/m328p; diff /tmp/m32{,8p}
Always good to double-check avrdude.conf entries. BTW, when I started my career as avrdude contributor I fixed the load extended address code for vvv large parts (think m2560) for a number of -c programmers. Glancing over stk500v2.c that looks wrong, too! It has the same tell-tale code that won't work with files with holes Lines 2456 to 2462 in 2f2a6c0 This is an independent problem, but still a problem. No doubt, @mcuee can confirm that using a wiring bootloader on a m2560 won't be able to handle those fiendish files with holes crossing over the 64k word boundary. |
@mcuee I think we have been here before: the terminal assumes the programmer has a working page erase if the function pointer |
It might actually be that this commit works as intended (it's been in place for over 10 years), but that it's uncovered a weakness of the |
@stefanrueger
Sorry just wonder how to do that. |
@stefanrueger Please refer to my earlier comments.
Summary: The root cause of the issue is the mega commit d742827 on 15 Sept 2011. The mega commit affects multiple programmers but some of them (like jtagmki, avrftdi, usbasp and usbtiny) have since fixed the issue. It does not seem to affect avr109/avr910 and STK500v1. Confirmed and need to be fixed: stk500v2, jtagmkii (AVR Dragon and AVR JTAGICE mkii) in ISP mode I can reproduce the issue with pickit4_isp. If that is the case, probably all modern Microchip tools are affected when using ISP ( Based on the test results, ATmega8/8515/8535, ATmega16/32/64/128 are affected. ATmega328P are not affected. |
Here is the output. |
Haha, I remember those testing experiences. On the other hand, it is interesting that wiring bootloader works in this case with your good hext file. Same for my STK500v2 with official FW (ATmega8535 based). |
|
PR #1265 fixed a long standing issue $455 with linuxgpio and linuxspi. It may be somewhat related to this issue. On the other hand, this issue may be different and likely due to firmware issue and we may have to use reverse engineering from Microchip Studio to see if there is any difference from Microchip Studio. |
|
There is no issue using Microchip Studio with the following hex file. Microchip Studio is okay.
avrdude git main run log: |
|
The following is with HHD Free Device Monitoring Studio, capturing the Serial Port (COM4) data when using Mircochip Studio 7.0 to program the ATmega8A.
|
|
Ah, yes, I remember we had narrowed it down to input files with a hole that covers at least one page. In your simple test example, the input file has two 64-byte blocks (64 bytes = 1 page): one with all 0xff at address 0 and the other one with all 0x00 at address 0x80 leaving a 64-byte hole at address 0x40. I have read through the [edit: question was answered above]
|
|
OK, reading through the previous posts, it looks like this has nothing to do with holes and everything to do with value polling on a page full of 0xff for these parts. Here is patch that delays when we ask STK500 to write a page using value polling when the page is full of poll bytes: diff --git a/src/stk500v2.c b/src/stk500v2.c
index 49a331f..e92cf8d 100644
--- a/src/stk500v2.c
+++ b/src/stk500v2.c
@@ -2162,6 +2162,13 @@ static int stk500isp_write_byte(const PROGRAMMER *pgm, const AVRPART *p, const A
return 0;
}
+
+// Are all n bytes pointed to by p the same byte chr?
+static int _is_all_chr(const unsigned char *p, size_t n, unsigned char chr) {
+ return n <= 0 || (*p == chr && memcmp(p, p+1, n-1) == 0);
+}
+
+
static int stk500v2_paged_write(const PROGRAMMER *pgm, const AVRPART *p, const AVRMEM *m,
unsigned int page_size,
unsigned int addr, unsigned int n_bytes)
@@ -2280,6 +2287,10 @@ static int stk500v2_paged_write(const PROGRAMMER *pgm, const AVRPART *p, const A
memcpy(buf+10,m->buf+addr, block_size);
result = stk500v2_command(pgm,buf,block_size+10, sizeof(buf));
+ if(commandbuf[3] & 0x20) // Value polling: might fail when page only has poll bytes
+ if(_is_all_chr(m->buf+addr, block_size, commandbuf[8]))
+ if(10+m->delay > 0)
+ usleep((10+m->delay)*1000);
if (result < 0) {
pmsg_error("write command failed\n");
return -1;
|
|
Here another idea: Don't program with value polling when the page only has poll bytes: diff --git a/src/stk500v2.c b/src/stk500v2.c
index 49a331f..650a4be 100644
--- a/src/stk500v2.c
+++ b/src/stk500v2.c
@@ -2162,6 +2162,13 @@ static int stk500isp_write_byte(const PROGRAMMER *pgm, const AVRPART *p, const A
return 0;
}
+
+// Are all n bytes pointed to by p the same byte chr?
+static int _is_all_chr(const unsigned char *p, size_t n, unsigned char chr) {
+ return n <= 0 || (*p == chr && memcmp(p, p+1, n-1) == 0);
+}
+
+
static int stk500v2_paged_write(const PROGRAMMER *pgm, const AVRPART *p, const AVRMEM *m,
unsigned int page_size,
unsigned int addr, unsigned int n_bytes)
@@ -2279,7 +2286,12 @@ static int stk500v2_paged_write(const PROGRAMMER *pgm, const AVRPART *p, const A
memcpy(buf+10,m->buf+addr, block_size);
- result = stk500v2_command(pgm,buf,block_size+10, sizeof(buf));
+ int do_write = 1;
+ if(commandbuf[3] & 0x20) // Value polling: might fail when page only has poll bytes
+ if(_is_all_chr(m->buf+addr, block_size, commandbuf[8]))
+ do_write = 0;
+
+ result = do_write? stk500v2_command(pgm,buf,block_size+10, sizeof(buf)): 0;
if (result < 0) {
pmsg_error("write command failed\n");
return -1; |
This seems to be in line with the Microchip Studio serial sniffer output. I will give this patch a try. |
Yes this fixed the issue. Great work! |
Just for understanding, I test this patch as well. It does not work. |
Tested with AVRISP mkii as well. |
|
One more test with PICKit 4 and current git main is good. |
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
The text was updated successfully, but these errors were encountered: