AVR 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: |
Andrzej Pietrasiewicz <andrzejtp> |
Sun 28 Jul 2019 03:39:39 PM UTC, comment #6: Please see https://www.avrfreaks.net/comment/2739451#comment-2739451
|
Andrzej Pietrasiewicz <andrzejtp> |
Sun 28 Jul 2019 03:37:03 PM UTC, comment #5:
|
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.
|
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.
|
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". |
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.
|
Anonymous |
Depends on the following items: None found
Items that depend on this one: None found
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 |
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?