[avrdude-dev] [bug #30680] Checking for all 0xff not best way to decide which pages to program

[anonymous]

URL:
  <http://savannah.nongnu.org/bugs/?30680>

                 Summary: Checking for all 0xff not best way to decide which
pages to program
                 Project: AVR Downloader/UploaDEr
            Submitted by: None
            Submitted on: Sat 07 Aug 2010 04:54:37 PM UTC
                Category: None
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: Mark Sullivan
        Originator Email: address@hidden
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

I am using -c arduino and -p m328p and an Intel-hex input file but this
should apply to any device which supports page write and any file format which
supports sparse addressing.

In fileio.c, the function ihex2b returns the max address written.

In stk500.c, in stk500_paged_write takes a parameter n_bytes to tell it how
many bytes to program.

It seems that n_bytes ultimately comes from the maxaddr returned by ihex2b. 
The number of bytes to program is only the same as the max addr if the file
starts at address 0, which it does not in my admittedly unusual application. 

In fact, my hex file can be sparse, generally, so even a start and end
address would not adequately describe it.

stk_500_paged_write also assumes that any page (in the file buffer) of all
0xff does not need to be programmed.  This assumes that everything was erased
before programming, which is not necessarily true, especially since chip_erase
doesn't seem to work in this configuration.  It would work if this test
operated on the original chip contents rather than the file buffer.

So, the way I think it should work is that ihex2b should build a bitmap of
the pages which it finds in the file.  And stk_500_paged_write should program
all of these pages, whether they are 0xff or not.  I've made this change to
the copy I'm using but it is a terrible hack and only works for Intel hex
files and the stk500 and 128 byte pages.

Even better:

To handle sparse input and also avoid unnecessary erase cycles, one could
have ihex2b build a bitmap of the WORDS it loads from the file.  Then the
programming code could, for each loaded word, compare the file buffer contents
to the chip contents and erase and program as required to make the chip match
the file but only for words which appeared in the file.  In certain cases,
this could involve erasing a page and reprogramming some of it from the
original chip contents and some of it from the file buffer.




    _______________________________________________________

Reply to this item at:

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

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