[bug #51320] linuxgpio and linuxspi problem: 0x00 written as 0xFF when byte count is less than 0x10 in hex file lines #455

avrs-admin · 2021-12-11T00:17:47Z

Mike Brandon smbrandonjr@gmail.com
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

avrs-admin · 2021-12-11T00:18:48Z

Mike
Fri 30 Jun 2017 12:03:35 AM UTC

Here is an intel hex file that will return a verification error due to "00" getting written as "FF".

(file #41079)

avrs-admin · 2021-12-11T00:18:50Z

Mike
Wed 05 Jul 2017 05:35:02 PM UTC

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.

avrs-admin · 2021-12-11T00:18:51Z

Mike
Tue 11 Jul 2017 06:56:57 PM UTC

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.

avrs-admin · 2021-12-11T00:18:53Z

Mike
Tue 18 Jul 2017 02:54:09 PM UTC

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.

avrs-admin · 2021-12-11T00:18:54Z

Andrzej Pietrasiewicz
Sun 28 Jul 2019 03:37:03 PM UTC

comment #2:

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.

avrs-admin · 2021-12-11T00:18:56Z

Andrzej Pietrasiewicz
Sun 28 Jul 2019 03:39:39 PM UTC

Please see https://www.avrfreaks.net/comment/2739451#comment-2739451

The problem is with hex file records containing an odd number of data bytes.

avrs-admin · 2021-12-11T00:18:57Z

Andrzej Pietrasiewicz
Wed 31 Jul 2019 08:24:23 PM UTC

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?

mcuee · 2022-06-03T12:35:01Z

Related issue with Mega2560 and linuxgpio. Probably this is the same as #458.

[bug #51497] avrdude not writing high byte using linuxgpio when data byte count is less than 0x10 #458

mcuee · 2022-07-10T14:13:17Z

I will try to test this soon with the above-mentioned hex file for ATmega2560.

mcuee · 2022-07-11T01:36:08Z

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.

mcuee · 2022-07-11T01:39:56Z

Not so sure if this has anything similar to the issue mentioned in #825 or #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;

``

mcuee · 2022-07-11T01:57:37Z

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.

mcuee · 2022-07-11T02:07:04Z

Not so sure if this has anything similar to the issue mentioned in #825 or #936.

Fix TPI memory writes for odd number of bytes #825

Fix Issue #918: Enable avrdude to send full input file incl trailing 0xff #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.

mcuee · 2022-07-11T02:24:16Z

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.

mcuee · 2022-07-11T08:27:22Z

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

stefanrueger · 2022-07-12T13:49:59Z

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

mcuee · 2022-07-12T14:06:24Z

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.

mcuee · 2022-07-31T14:05:51Z

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.

mcuee · 2023-01-05T00:21:00Z

I can confirm that PR #1265 fixed this issue.

Analysis by @stefanrueger
#1263 (comment)

mcuee added bug Something isn't working unconfirmed Maybe a bug, needs to be reproduced by someone else and removed bug Something isn't working labels Jun 20, 2022

mcuee mentioned this issue Jul 10, 2022

[bug #51497] avrdude not writing high byte using linuxgpio when data byte count is less than 0x10 #458

Closed

mcuee added bug Something isn't working and removed unconfirmed Maybe a bug, needs to be reproduced by someone else labels Jul 10, 2022

mcuee mentioned this issue Jul 11, 2022

linuxgpio issues #932

Closed

mcuee mentioned this issue Aug 5, 2022

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

Closed

mcuee changed the title ~~[bug #51320] 0x00 written as 0xFF when byte count is less than 0x10~~ [bug #51320] linuxgpio and linuxspi problem: 0x00 written as 0xFF when byte count is less than 0x10 in hex file lines Nov 28, 2022

mcuee mentioned this issue Jan 4, 2023

linuxgpio and linuxspi issue: Official .hex from Atmel doesn't program correctly #1263

Closed

stefanrueger linked a pull request Jan 4, 2023 that will close this issue

Ensure full words are loaded, low-byte first, for ISP programming #1265

Merged

mcuee mentioned this issue Jan 5, 2023

Ensure full words are loaded, low-byte first, for ISP programming #1265

Merged

stefanrueger closed this as completed in #1265 Jan 5, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[bug #51320] linuxgpio and linuxspi problem: 0x00 written as 0xFF when byte count is less than 0x10 in hex file lines #455

[bug #51320] linuxgpio and linuxspi problem: 0x00 written as 0xFF when byte count is less than 0x10 in hex file lines #455

avrs-admin commented Dec 11, 2021

avrs-admin commented Dec 11, 2021

avrs-admin commented Dec 11, 2021

avrs-admin commented Dec 11, 2021

avrs-admin commented Dec 11, 2021

avrs-admin commented Dec 11, 2021

avrs-admin commented Dec 11, 2021

avrs-admin commented Dec 11, 2021 •

edited by MCUdude

Loading

mcuee commented Jun 3, 2022 •

edited

Loading

mcuee commented Jul 10, 2022 •

edited

Loading

mcuee commented Jul 11, 2022 •

edited

Loading

mcuee commented Jul 11, 2022 •

edited by MCUdude

Loading

mcuee commented Jul 11, 2022

mcuee commented Jul 11, 2022

mcuee commented Jul 11, 2022 •

edited

Loading

mcuee commented Jul 11, 2022 •

edited

Loading

stefanrueger commented Jul 12, 2022

mcuee commented Jul 12, 2022 •

edited

Loading

mcuee commented Jul 31, 2022

mcuee commented Jan 5, 2023

[bug #51320] linuxgpio and linuxspi problem: 0x00 written as 0xFF when byte count is less than 0x10 in hex file lines #455

[bug #51320] linuxgpio and linuxspi problem: 0x00 written as 0xFF when byte count is less than 0x10 in hex file lines #455

Comments

avrs-admin commented Dec 11, 2021

avrs-admin commented Dec 11, 2021

avrs-admin commented Dec 11, 2021

avrs-admin commented Dec 11, 2021

avrs-admin commented Dec 11, 2021

avrs-admin commented Dec 11, 2021

avrs-admin commented Dec 11, 2021

avrs-admin commented Dec 11, 2021 • edited by MCUdude Loading

mcuee commented Jun 3, 2022 • edited Loading

mcuee commented Jul 10, 2022 • edited Loading

mcuee commented Jul 11, 2022 • edited Loading

mcuee commented Jul 11, 2022 • edited by MCUdude Loading

mcuee commented Jul 11, 2022

mcuee commented Jul 11, 2022

mcuee commented Jul 11, 2022 • edited Loading

mcuee commented Jul 11, 2022 • edited Loading

stefanrueger commented Jul 12, 2022

mcuee commented Jul 12, 2022 • edited Loading

mcuee commented Jul 31, 2022

mcuee commented Jan 5, 2023

avrs-admin commented Dec 11, 2021 •

edited by MCUdude

Loading

mcuee commented Jun 3, 2022 •

edited

Loading

mcuee commented Jul 10, 2022 •

edited

Loading

mcuee commented Jul 11, 2022 •

edited

Loading

mcuee commented Jul 11, 2022 •

edited by MCUdude

Loading

mcuee commented Jul 11, 2022 •

edited

Loading

mcuee commented Jul 11, 2022 •

edited

Loading

mcuee commented Jul 12, 2022 •

edited

Loading