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).
|
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?
|
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.
|
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.
|
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
|
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.
|
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.
|
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.
|
Mon 10 Oct 2011 12:21:19 PM UTC, comment #1:
Over to David for a comment, as he introduced the mentioned
changes.
|
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
|