bugAVR Downloader/UploaDEr - Bugs: bug #30680, Checking for all 0xff not best way...

 
 

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

bug #30680: Checking for all 0xff not best way to decide which pages to program

Submitted by:  None
Submitted on:  Sat 07 Aug 2010 04:54:37 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: DuplicatePrivacy: Public
Assigned to: NoneOriginator Name: Mark Sullivan
Originator Email: -unavailable-Open/Closed: Closed
Release: NoneProgrammer hardware: 
Device type: 

Sun 08 Aug 2010 06:59:26 PM UTC, comment #1:

I know that the current implementation leaves a bit to be
desired. Alas, there's currently nobody who has the time
and energy to implement the complete rework that would be
needed in order to avoid the underlying problem, that any
actual file information is lost by the time the programming
is started.

Anyway, you (respectively your bootloader) makes one
assumption which is fundamentally wrong, and which in turn
gives the implementation the right to skip any flash cell
that would be written to 0xffff: flash bits can only be
written from 1 to 0, consequently, any attempt to write a
1 bit is essentially a nop. As it is a nop, it can be skipped.
(In order to return a flash cell back to 1 bits, it must be
erased.)

The problem here is apparently an implementation flaw in the
Arduino bootloader. It has already been discussed in
bug #30061, so I'm closing this bug here as a duplicate of
that one.

Joerg Wunsch <joerg_wunsch>
Project Administrator
Sat 07 Aug 2010 04:54:37 PM UTC, original submission:

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.

Anonymous

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -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 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 08 Aug 2010 06:59:26 PM UTCjoerg_wunschStatusNone=>Duplicate
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1