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

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Andrzej Pietrasiewicz
URL:
  <http://savannah.nongnu.org/bugs/?51320>

                 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: [hidden email]
             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.
<http://savannah.nongnu.org/bugs/download.php?file_id=41052>
-------------------------------------------------------
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.
<http://savannah.nongnu.org/bugs/download.php?file_id=41053>
-------------------------------------------------------
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.
<http://savannah.nongnu.org/bugs/download.php?file_id=41054>

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?51320>

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


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

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

Andrzej Pietrasiewicz
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:

  <http://savannah.nongnu.org/bugs/?51320>

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


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

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

Andrzej Pietrasiewicz
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.PNG    Size:30 KB
File name: blink-mod-bitbang-read.PNG     Size:40 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?51320>

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


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

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

Andrzej Pietrasiewicz
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:

  <http://savannah.nongnu.org/bugs/?51320>

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


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

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

Andrzej Pietrasiewicz
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:

  <http://savannah.nongnu.org/bugs/?51320>

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


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

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

  <https://savannah.nongnu.org/bugs/?51320>

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


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

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

  <https://savannah.nongnu.org/bugs/?51320>

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


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

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

  <https://savannah.nongnu.org/bugs/?51320>

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


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev