avrdude
avrdude copied to clipboard
avrdudes
[bug #51320] 0x00 written as 0xFF when byte count is less than 0x10
Mike Brandon [email protected] Mon 26 Jun 2017 08:13:10 PM UTC Programmer hardware: linuxgpio Device type: m2650
I have two different .hex files (unfortunately I am unable to share entire .hex files as I do not own them). Both write and verify fine when using AVR Studio and an AVRISP programmer.
When using avrdude with linuxgpio, the write process completes but the verification process returns an error. In both files it occurs on lines of the .hex file where the data byte count is less than 0x10 (this is the only common theme I have been able to identify). When I look at the specific address mentioned by avrdude for the verification error, the original data that SHOULD have been written was 0x00. The data that WAS written was 0xFF.
The attached files only pertain to one of the hex files I have experienced this with.
file #41054: 0x40ca-read.PNG file #41053: avrdude-write-read.PNG file #41052: 0x40ca-data.PNG file #41079: blink-2560-mod.hex file #41127: blink-mod-bitbang-read.PNG file #41126: blink-mod-bitbang-write.PNG
This issue was migrated from https://savannah.nongnu.org/bugs/?51320
Mike
Here is an intel hex file that will return a verification error due to "00" getting written as "FF".
Mike
In further troubleshooting of my issue, I did examine the verbose output during the writing and flashing of the blink-2560-mod hex file. Interestingly, the bitbang_cmd() output shows that it did write "00" for the byte in question. During the read, "FF" is being read. I do know that if I read the firmware with AVR Studio it will also confirm the byte mismatch so even though avrdude bitbang shows "00", it is either not writing it (and FF is a remnant of the initial chip erase) or it is writing FF.
I have attached two more images showing the verbose output during this scenario.
Mike
In further testing, the issue is not specific to trying to write "00". I will receive a verification error anytime the data byte count is less than 0x10 AND the last data byte != 0xFF.
I have verified this response with numerous .hex files on the Atmega1284 and Atmega 2560 chips.
Atmel Studio will write and verify these same .hex files without error.
Mike
After further troubleshooting, I believe I have discovered more precisely what is causing the verification error and in an effort to not bury it below this bug thread, I want to open a new bug. This bug can be closed.
Andrzej Pietrasiewicz
In further troubleshooting of my issue, I did examine the verbose output during the writing and flashing of the blink-2560-mod hex file. Interestingly, the bitbang_cmd() output shows that it did write "00" for the byte in question. During the read, "FF" is being read. I do know that if I read the firmware with AVR Studio it will also confirm the byte mismatch so even though avrdude bitbang shows "00", it is either not writing it (and FF is a remnant of the initial chip erase) or it is writing FF.
I have attached two more images showing the verbose output during this scenario.
Andrzej Pietrasiewicz
Please see https://www.avrfreaks.net/comment/2739451#comment-2739451
The problem is with hex file records containing an odd number of data bytes.
Andrzej Pietrasiewicz
I have a solution - if an ihex record has odd length then mark the missing high byte as allocated and let it contain 0xff:
diff --git a/fileio.c b/fileio.c
index 02c50ab..e3c82a4 100644
--- a/fileio.c
+++ b/fileio.c
@@ -334,6 +334,10 @@ static int ihex2b(char * infile, FILE * inf,
mem->buf[nextaddr+i] = ihex.data[i];
mem->tags[nextaddr+i] = TAG_ALLOCATED;
}
+ if (ihex.reclen & 0x1) {
+ mem->buf[nextaddr+i] = 0xff;
+ mem->tags[nextaddr+i] = TAG_ALLOCATED;
+ }
if (nextaddr+ihex.reclen > maxaddr)
maxaddr = nextaddr+ihex.reclen;
break;
But why is the record length odd in the first place if flash locations are 2-byte locations?
Related issue with Mega2560 and linuxgpio. Probably this is the same as #458.
- https://github.com/avrdudes/avrdude/issues/458
I will try to test this soon with the above-mentioned hex file for ATmega2560.
I can confirm that there is a bug here.
pi@raspberrypi:~/Desktop/build/avr/avrdude/build_linux/src $ sudo ./avrdude -C ./avrdude.conf
-c linuxgpio -P GPIO -p m2560 -U flash:w:./blink-2560-mod.hex:i
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e9801 (probably m2560)
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 "./blink-2560-mod.hex"
avrdude: writing flash (1490 bytes):
Writing | ################################################## | 100% 0.35s
avrdude: 1490 bytes of flash written
avrdude: verifying flash memory against ./blink-2560-mod.hex:
Reading | ################################################## | 100% 0.64s
avrdude: verification error, first mismatch at byte 0x05ce
0xff != 0x00
avrdude: verification error; content mismatch
avrdude done. Thank you.
Not so sure if this has anything similar to the issue mentioned in #825 or #936.
- #825
- #936
The patch with a bit better formatting.
diff --git a/fileio.c b/fileio.c
index 02c50ab..e3c82a4 100644
--- a/fileio.c
+++ b/fileio.c
@@ -334,6 +334,10 @@ static int ihex2b(char * infile, FILE * inf,
mem->buf[nextaddr+i] = ihex.data[i];
mem->tags[nextaddr+i] = TAG_ALLOCATED;
}
+ if (ihex.reclen & 0x1) {
+ mem->buf[nextaddr+i] = 0xff;
+ mem->tags[nextaddr+i] = TAG_ALLOCATED;
+ }
if (nextaddr+ihex.reclen > maxaddr)
maxaddr = nextaddr+ihex.reclen;
break;
``
I can confirm that the patch fixed the issue.
pi@raspberrypi:~/Desktop/build/avr/avrdude_issue455 $ git diff
diff --git a/src/fileio.c b/src/fileio.c
index 7c021ce..f5e7e32 100644
--- a/src/fileio.c
+++ b/src/fileio.c
@@ -336,6 +336,12 @@ static int ihex2b(char * infile, FILE * inf,
mem->buf[nextaddr+i] = ihex.data[i];
mem->tags[nextaddr+i] = TAG_ALLOCATED;
}
+
+ if(ihex.reclen & 0x1) {
+ mem->buf[nextaddr+i] = 0xff;
+ mem->tags[nextaddr+i] = TAG_ALLOCATED;
+ }
+
if (nextaddr+ihex.reclen > maxaddr)
maxaddr = nextaddr+ihex.reclen;
break;
pi@raspberrypi:~/Desktop/build/avr/avrdude_issue455/build_linux/src $ sudo ./avrdude -C ./avrdude.conf
-c linuxgpio -P GPIO -p m2560 -U flash:w:./blink-2560-mod.hex:i
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e9801 (probably m2560)
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 "./blink-2560-mod.hex"
avrdude: writing flash (1490 bytes):
Writing | ################################################## | 100% 0.33s
avrdude: 1490 bytes of flash written
avrdude: verifying flash memory against ./blink-2560-mod.hex:
Reading | ################################################## | 100% 0.64s
avrdude: 1490 bytes of flash verified
avrdude done. Thank you.
Not so sure if this has anything similar to the issue mentioned in #825 or #936.
@stefanrueger Looks like #936 does not help in this case. Still please take a look to see if there are similarities here.
pi@raspberrypi:~/Desktop/build/avr/avrdude_sr/build_linux/src $ sudo ./avrdude -C ./avrdude.conf
-c linuxgpio -P GPIO -p m2560 -U flash:w:./blink-2560-mod.hex:i
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e9801 (probably m2560)
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 "./blink-2560-mod.hex"
avrdude: writing flash (1490 bytes):
Writing | ################################################## | 100% 0.34s
avrdude: 1490 bytes of flash written
avrdude: verifying flash memory against ./blink-2560-mod.hex:
Reading | ################################################## | 100% 0.65s
avrdude: verification error, first mismatch at byte 0x05ce
0xff != 0x00
avrdude: verification error; content mismatch
avrdude done. Thank you.
I can confirm that linuxspi has the same issue and the same patch works to fix the issue.
pi@raspberrypi:~/Desktop/build/avr/avrdude/build_linux/src $ ./avrdude -C ./avrdude.conf -p m2560
-c linuxspi -P /dev/spidev0.0:/dev/gpiochip0 -U flash:w:blink-2560-mod.hex:i
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e9801 (probably m2560)
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 "blink-2560-mod.hex"
avrdude: writing flash (1490 bytes):
Writing | ################################################## | 100% 0.35s
avrdude: 1490 bytes of flash written
avrdude: verifying flash memory against blink-2560-mod.hex:
Reading | ################################################## | 100% 0.90s
avrdude: verification error, first mismatch at byte 0x05ce
0xff != 0x00
avrdude: verification error; content mismatch
avrdude done. Thank you.
pi@raspberrypi:~/Desktop/build/avr/avrdude_issue455/build_linux/src $ ./avrdude -C ./avrdude.conf
-p m2560 -c linuxspi -P /dev/spidev0.0:/dev/gpiochip0 -U flash:w:blink-2560-mod.hex:i
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e9801 (probably m2560)
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 "blink-2560-mod.hex"
avrdude: writing flash (1490 bytes):
Writing | ################################################## | 100% 0.36s
avrdude: 1490 bytes of flash written
avrdude: verifying flash memory against blink-2560-mod.hex:
Reading | ################################################## | 100% 0.95s
avrdude: 1490 bytes of flash verified
avrdude done. Thank you.
BTW, there is no issue with an STK500v2 and an AVRISP mkii clone. This is kind of strange since the fix is not specific to the linuxgpio/linuxspi programmer.
PS C:\work\avr\avrdude_test\avrdude-7.0_bin64> .\avrdude.exe -c stk500v2 -P COM6
-qqp m2560 -U flash:w:.\blink-2560-mod.hex:i && echo OK
OK
PS C:\work\avr\avrdude_test\avrdude-7.0_bin64> .\avrdude.exe -c avrisp2 -qqp m2560
-U flash:w:.\blink-2560-mod.hex:i && echo OK
OK
Same for a PICKit 2 with the fix for issue #1004 (Pull request #1023).
PS C:\work\avr\avrdude_test\avrdude-7.0_bin64> .\avrdude_issue1004v3.exe -c pickit2 -qqp m2560
-U flash:w:.\blink-2560-mod.hex:i && echo OK
OK
@mcuee I had a look and I am puzzled by the patch. A hex file can piece together an application in whichever way it likes, eg, a 10-byte contiguous input file might well be described in a hex file as one record of 7 bytes followed by another record of 3 bytes. It should not matter how the hex file looks like, what matters is how the resulting file after reading looks like. On that grounds alone I would reject the patch.
So, if the patch works in the observed case, it must have been something else that helped...
So, if the patch works in the observed case, it must have been something else that helped...
I agree. I was puzzled as well because the patch is not really related to linuxgpio and linuxspi. So I guess something in the linuxgpio and linuxspi may be the problem.
Therefore I agree the patch is probably not addressing the root cause.
So, if the patch works in the observed case, it must have been something else that helped...
@stefanrueger Just wondering if you have some pointer to further debug the issue. Thanks.
I can confirm that PR #1265 fixed this issue.
Analysis by @stefanrueger https://github.com/avrdudes/avrdude/issues/1263#issuecomment-1371159492