bugAVR Downloader/UploaDEr - Bugs: bug #31699, ihex : unhandled ext. linear...

 
 

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

bug #31699: ihex : unhandled ext. linear address records and unoptimized empty (0xff) space

Submitter:  Georg Garrecht <gg2410>
Submitted:  Thu 18 Nov 2010 06:14:42 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Privacy:  Public
Assigned to:  joerg_wunsch Originator Name:  gg2410
Open/Closed:  Closed Release:  None
Programmer hardware:  Device type: 

Thu 15 Sep 2011 04:00:05 PM UTC, comment #1: 

Problem #1 is fixed with the recent introduction of memory
region tagging: only those memory regions where actual content
has been read for from a file are written to now.

You are encouraged to test the new feature set, but by now,
you'll have to do that straight from SVN trunk.

I cannot reproduce problem #2, and I can assure you we've
been using AVRDUDE to program bootloaders (or mixed application +
bootloader area code, for SPM access from the application)
for years now.

I just verified all this works fine, by simply redirecting
the .text section of an example program to 0x1f000, and
writing it to the flash of an ATmega1281 device.  All is fine,
the program text ends up in the correct location, and the
program runs as expected (ignoring the leading 0xffff program
words).

If you've really got a reproducible example for this, please
reopen the bug report.

Joerg Wunsch <joerg_wunsch>
Group administrator
Thu 18 Nov 2010 06:14:42 PM UTC, original submission:  

I found a very strange problem, which makes it nearly impossible to write e.g. a bootloader into an ATMEGA in a seriously short time.

For specialists, this should be easy to fix.


Version : 5.10

Following commandline:

avrdude -p m128 -c ponyser -P com1: -e -U flash:w:test55.hex


used with following sole hexfile content:

:20F0000011241FBECFEFD0E1DEBFCDBF11E0A0E0B1E0E6E3F6EF01E00BBF02C007900D92F3
:00000001FF


Problem #1:
===========
Although the flash memory is cleared, the software always tries to write full 61472 bytes into the Atmega. Most of this writing is unnecessary as the bytes are all 0xFF after a flash erase.
This way, it takes minutes instead of 2-3 seconds to write a small portion of code into the upper part of the flash.

It seems that it doesn't skip writing blocks of 0xFF starting at beginning of the Flash memory up to the address where it is needed to write the first byte != 0.

even worse: Problem #2
======================
adding
  :020000040001F9 
as the first line of the hex file should relocate the writing process to Flash address 0x1F000.

Instead, the software still tries to write only 61472 bytes.
The dump which I get when using cmd-line option "-n" shows this clearly.
This way, it is impossible to write a bootloader into the upper few KB's of the 128K Flash.

Is the AVRDUDE Software perhaps not able to write more than 64KB ?

Please look into this, as it is clearly not only of importance for me.

Many thanxxxxxxxxxx

Georg


Georg Garrecht <gg2410>

 

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

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

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

    Date Changed by Updated Field Previous Value => Replaced by
    2011-09-15 joerg_wunsch StatusNone Fixed
        Assigned toNone joerg_wunsch
        Open/ClosedOpen Closed
    2010-11-18 gg2410 Carbon-Copy- Added gg2410

    Back to the top

    Powered by Savane 3.15-e6e5.
    Corresponding source code