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)

Submitted by:  None
Submitted on:  Mon 10 Oct 2011 11:19:40 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: FixedPrivacy: Public
Assigned to: Joerg Wunsch <joerg_wunsch>Originator Name: tomcrus
Originator Email: -unavailable-Open/Closed: Closed
Release: NoneProgrammer hardware: 
Device type: 

(Jump to the original submission 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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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

 

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
  • -unavailable- added by elize1b2 (Posted a comment)
  • -unavailable- added by dhoerl (Posted a comment)
  • -unavailable- added by joerg_wunsch (Posted a comment)
  • -unavailable- added by None (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 10 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 10 Oct 2011 02:26:21 PM UTCjoerg_wunschAssigned todhoerl=>joerg_wunsch
      Open/ClosedOpen=>Closed
    Mon 10 Oct 2011 01:52:39 PM UTCjoerg_wunschStatusConfirmed=>Fixed
      Assigned tojoerg_wunsch=>dhoerl
    Mon 10 Oct 2011 12:42:59 PM UTCjoerg_wunschAssigned todhoerl=>joerg_wunsch
    Mon 10 Oct 2011 12:36:26 PM UTCjoerg_wunschStatusNone=>Confirmed
    Mon 10 Oct 2011 12:21:19 PM UTCjoerg_wunschAssigned toNone=>dhoerl
    Mon 10 Oct 2011 11:19:40 AM UTCNoneAttached 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.1-cleanup1