bugAVR Downloader/UploaDEr - Bugs: bug #51320, 0x00 written as 0xFF when byte...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #51320: 0x00 written as 0xFF when byte count is less than 0x10

Submitter:  None
Submitted:  Mon 26 Jun 2017 08:13:10 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  None Privacy:  Public
Assigned to:  None Originator Name:  Mike Brandon
Originator Email:  -email is unavailable- Open/Closed:  Open
Release:  6.3 Programmer hardware:  linuxgpio
Device type:  m2650

Jump to the original submission

Wed 31 Jul 2019 08:24:23 PM UTC, comment #7: 

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?

Andrzej Pietrasiewicz <andrzejtp>
Sun 28 Jul 2019 03:39:39 PM UTC, comment #6: 

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 <andrzejtp>
Sun 28 Jul 2019 03:37:03 PM UTC, comment #5: 


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

Andrzej Pietrasiewicz <andrzejtp>
Tue 18 Jul 2017 02:54:09 PM UTC, comment #4: 

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.

Mike <smbrandonjr>
Tue 11 Jul 2017 06:56:57 PM UTC, comment #3: 

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 <smbrandonjr>
Wed 05 Jul 2017 05:35:02 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.


Mike <smbrandonjr>
Fri 30 Jun 2017 12:03:35 AM UTC, comment #1: 

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

(file #41079)

Mike <smbrandonjr>
Mon 26 Jun 2017 08:13:10 PM UTC, original submission:  

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.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #41126:  blink-mod-bitbang-write.PNG added by smbrandonjr (30KiB - image/png - blink-mod-bitbang-write: has line highlighted showing the writing of "00". blink-mod-bitbang-read: has the line highlighted showing the read of "FF")
file #41127:  blink-mod-bitbang-read.PNG added by smbrandonjr (40KiB - image/png - blink-mod-bitbang-write: has line highlighted showing the writing of "00". blink-mod-bitbang-read: has the line highlighted showing the read of "FF")
file #41079:  blink-2560-mod.hex added by smbrandonjr (4KiB - application/octet-stream)
file #41052:  0x40ca-data.PNG added by None (13KiB - image/png - 0x40ca-data shows the original data that should be writte. 0x40ca-read shows the data that was read after flashing.)
file #41053:  avrdude-write-read.PNG added by None (95KiB - image/png - 0x40ca-data shows the original data that should be writte. 0x40ca-read shows the data that was read after flashing.)
file #41054:  0x40ca-read.PNG added by None (23KiB - image/png - 0x40ca-data shows the original data that should be writte. 0x40ca-read shows the data that was read after flashing.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by andrzejtp (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-07-05 smbrandonjr Attached File- Added blink-mod-bitbang-write.PNG, #41126
        Attached File- Added blink-mod-bitbang-read.PNG, #41127
    2017-06-30 smbrandonjr Attached File- Added blink-2560-mod.hex, #41079
    2017-06-26 None Attached File- Added 0x40ca-data.PNG, #41052
        Attached File- Added avrdude-write-read.PNG, #41053
        Attached File- Added 0x40ca-read.PNG, #41054

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code