bugAVR Downloader/UploaDEr - Bugs: bug #34518, loading intel hex files > 64k...

 
 

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

bug #34518: loading intel hex files > 64k using record-type 4 (Extended Linear Address Record)

Submitter:  None
Submitted:  Mon 10 Oct 2011 11:19:40 AM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Privacy:  Public
Assigned to:  joerg_wunsch Originator Name:  tomcrus
Originator Email:  -email is unavailable- Open/Closed:  Closed
Release:  None Programmer hardware: 
Device type: 

Jump to the original submission

Fri 21 Oct 2011 08:07:46 AM UTC, comment #9: 

What you're describing here is unrelated to bug #34518 but
is essentially the problem mentioned in bug #28744 (which
is still unresolved yet).

Joerg Wunsch <joerg_wunsch>
Group administrator
Fri 21 Oct 2011 07:23:18 AM UTC, comment #8: 

Hi all,

I am using avrdude to flash bootloader and application hex file. I can program the application hex file but when i tried to flash the boot loader, i got an error message.
Programmer: avr dragon
Controller: atmega16a4

command: avrdude -c dragon_pdi -D -p x16a4 -v -P usb -U boot:w:Boot.hex

response:

avrdude: Device signature = 0x1e9441
avrdude: reading input file "Boot.hex"
avrdude: input file Boot.hex auto detected as Intel Hex
avrdude: ERROR: address 0x4010 out of range at line 1 of Boot.hex
avrdude: write to file 'Boot.hex' failed

command: avrdude -c dragon_pdi -D -p x16a4 -v -P usb -U flash:w:Boot.hex

response:

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0xff != 0x0c
avrdude: verification error, content mismatch

I tried both windows with 5.11 and linux with 5.11.1. I have the same problem. What should i do?

Elif <elize1b2>
Mon 10 Oct 2011 02:26:21 PM UTC, comment #7: 

David cannot test it anymore on the AVR32.

As it clearly fixes the original bug, I close this PR.

Joerg Wunsch <joerg_wunsch>
Group administrator
Mon 10 Oct 2011 01:52:39 PM UTC, comment #6: 

I committed a fix in r1017 that approaches all this a different
way.

Instead of trying to figure out the file offset from the first
record of the file, pass it on to the read routine, based on
the device and memory configuration.  If the device is an
AVR32, the memory offset (which has already been present in
avrdude.conf anyway) is expected to be present in the file
itself.

This is now also implemented in the S-record routine (which
completely lacked a similar logic before), as well as in the
routines to write back Intel hex or S-record files.

(It's quite possible this needs to be extended beyond the
AVR32, e.g. to fix the bootloader write issues for Xmega
devices.)

David, please test this is doing the right thing on the
AVR32.

Joerg Wunsch <joerg_wunsch>
Group administrator
Mon 10 Oct 2011 01:47:30 PM UTC, comment #5: 

Hah - yes - I was looking at the code and trying to remember. AVR32 required addresses that did not begin at 0. So in this mode, you set the starting address somewhere then you need to write the number of bytes written. That's what its all there for.

For those using offsets of "0" - the common case - the offsetaddr should have no affect. This was my intent in the way it was coded - that for most people using "0" the variable would not do anything.

It did work fine for me - I ended up having to download tables at crazy addresses at year ago and it was working fine for me then.

David

David Hoerl <dhoerl>
Mon 10 Oct 2011 12:42:59 PM UTC, comment #4: 

OK, after digging through some old emails, I found the
issue David was trying to wrok around:

"This is because of the issue with AVR32 using address offset 0x80000000"

So it seems the AVR32 has a large difference between the
actual (CPU) addresses given in the file, and the addresses
to be used when programming the device memory (or maintain
the device's memory image).

Similar things would happen if we attempted to extend
AVRDUDE to e.g. ARM devices where the flash e.g. starts at
an offset of 0x400000.

I suggest to move this out of the file handling code, and
rather have the device description (in avrdude.conf)
reflect the memorie's base offset which has to be
subtracted from each address provided in the file.

Joerg Wunsch <joerg_wunsch>
Group administrator
Mon 10 Oct 2011 12:36:07 PM UTC, comment #3: 

After looking into that function, I cannot figure out the
purpose of `offsetaddr' either, and would suggest removing
it.

Anyway, David must have had something in mind when
writing this, so maybe he can explain that, and possibly
also show us an example file where this code is needed or
useful for.

Joerg Wunsch <joerg_wunsch>
Group administrator
Mon 10 Oct 2011 12:25:27 PM UTC, comment #2: 


> After looking into fileio.c I came accross the function
> ihex2b(), that already had several changes according to
> the >64k problem as can be seen in revs 851, 880, 928.


Well, r928 reverted the combined change from r851 and r880:

j@uriah 604% svn diff -r 816:928 fileio.c | wc
       0       0       0

All this was re-implemented in r929, so that's the specific
change to look at here.

Joerg Wunsch <joerg_wunsch>
Group administrator
Mon 10 Oct 2011 12:21:19 PM UTC, comment #1: 

Over to David for a comment, as he introduced the mentioned
changes.

Joerg Wunsch <joerg_wunsch>
Group administrator
Mon 10 Oct 2011 11:19:40 AM UTC, original submission:  

I just upgraded to avrdude 5.11.1, because of another bug recently fixed.

But opposed to avrdude 5.8 - that I was using before - I'm unable to properly flash my bootloader to an atmega128's boot-section now, if the hex-files uses the hex-record-type 4 (extended linear address record).

The problem can be easily reproduced flashing the attached file avr-bootloader.hex.qrUq5r to a device and subsequently reading it back again. I already did these steps and attached also the read-back version; see avr-bootloader.hex.read and cmd-prompt.txt for the command-output...
Comparing both files it can be seend, that the extended linear offset of 64k (first line in original file) seems to get skipped completely.

After looking into fileio.c I came accross the function ihex2b(), that already had several changes according to the >64k problem as can be seen in revs 851, 880, 928.
Now I think my problem is caused by the local variable offsetaddr (that's purpose I cannot understand). Removing all this offsetaddr-stuff (meaning to return this function to the state of rev 816, like in avrdude 5.8) solved my issue.

Can anybody responsible please explain me the purpose of this offsetaddr-variable. It seems it was introduced in rev 851, but the given comment "AVR32" doesn't say anything meaningful and I don't know what differences there are when reading intel-hex-files for avr32-architecture...

Greetings tomcrus

Anonymous

 

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

Attached Files
file #24127:  avr-bootloader.hex.qrUq5r added by None (160B - application/octet-stream)
file #24128:  avr-bootloader.hex.read added by None (133KiB - application/octet-stream)
file #24129:  cmd-prompt.txt added by None (2KiB - text/plain)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by elize1b2 (Posted a comment)
  • -email is unavailable- added by dhoerl (Posted a comment)
  • -email is unavailable- added by joerg_wunsch (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    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 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-10-10 joerg_wunsch Assigned todhoerl joerg_wunsch
        Open/ClosedOpen Closed
    2011-10-10 joerg_wunsch StatusConfirmed Fixed
        Assigned tojoerg_wunsch dhoerl
    2011-10-10 joerg_wunsch Assigned todhoerl joerg_wunsch
    2011-10-10 joerg_wunsch StatusNone Confirmed
    2011-10-10 joerg_wunsch Assigned toNone dhoerl
    2011-10-10 None Attached File- Added avr-bootloader.hex.qrUq5r, #24127
        Attached File- Added avr-bootloader.hex.read, #24128
        Attached File- Added cmd-prompt.txt, #24129

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code