[avrdude-dev] [bug #51320] 0x00 written as 0xFF when byte count is less than 0x10

[Andrzej Pietrasiewicz]

Follow-up Comment #7, bug #51320 (project avrdude):

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?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/


___
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev

[avrdude-dev] [bug #51320] 0x00 written as 0xFF when byte count is less than 0x10

[Andrzej Pietrasiewicz]

Follow-up Comment #6, bug #51320 (project avrdude):

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

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

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/


___
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev

[avrdude-dev] [bug #51320] 0x00 written as 0xFF when byte count is less than 0x10

[Andrzej Pietrasiewicz]

Follow-up Comment #5, bug #51320 (project avrdude):


[comment #2 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.
> 
> (file #41126, file #41127)

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/


___
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev

[avrdude-dev] [bug #51320] 0x00 written as 0xFF when byte count is less than 0x10

[Mike]

Follow-up Comment #4, bug #51320 (project avrdude):

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.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev

[avrdude-dev] [bug #51320] 0x00 written as 0xFF when byte count is less than 0x10

[Mike]

Follow-up Comment #3, bug #51320 (project avrdude):

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.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev

[avrdude-dev] [bug #51320] 0x00 written as 0xFF when byte count is less than 0x10

[Mike]

Follow-up Comment #2, bug #51320 (project avrdude):

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.

(file #41126, file #41127)
___

Additional Item Attachment:

File name: blink-mod-bitbang-write.PNGSize:30 KB
File name: blink-mod-bitbang-read.PNG Size:40 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev

[avrdude-dev] [bug #51320] 0x00 written as 0xFF when byte count is less than 0x10

[Mike]

Follow-up Comment #1, bug #51320 (project avrdude):

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

(file #41079)
___

Additional Item Attachment:

File name: blink-2560-mod.hex Size:4 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev

[avrdude-dev] [bug #51320] 0x00 written as 0xFF when byte count is less than 0x10

[anonymous]

URL:
  

 Summary: 0x00 written as 0xFF when byte count is less than
0x10
 Project: AVR Downloader/UploaDEr
Submitted by: None
Submitted on: 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: smbrando...@gmail.com
 Open/Closed: Open
 Release: 6.3
 Discussion Lock: Any
 Programmer hardware: linuxgpio
 Device type: m2650

___

Details:

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 Attachments:


---
Date: Mon 26 Jun 2017 08:13:10 PM UTC  Name: 0x40ca-data.PNG  Size: 13kB   By:
None
0x40ca-data shows the original data that should be writte. 0x40ca-read shows
the data that was read after flashing.

---
Date: Mon 26 Jun 2017 08:13:10 PM UTC  Name: avrdude-write-read.PNG  Size:
95kB   By: None
0x40ca-data shows the original data that should be writte. 0x40ca-read shows
the data that was read after flashing.

---
Date: Mon 26 Jun 2017 08:13:10 PM UTC  Name: 0x40ca-read.PNG  Size: 23kB   By:
None
0x40ca-data shows the original data that should be writte. 0x40ca-read shows
the data that was read after flashing.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev