RE: [avr-gcc-list] bootloader: replace bootloader with anew bootloader

[Mark E. Scott Jr.]

I don't know if this applies to the AVR world, but on my PIC project, I
would remote download (over cellular, stored in FRAM), a new firmware
release.  The standard bootloader would pull the code from the FRAM and
replace the ROM with the new firmware.  Then, the new firmware would
detect an outdated bootloader, and overwrite the bootloader section.
Now, there was a small window of time in which you could lose power and
hose the system, but it was incredibly small.

Without a large amount of extra NVRAM storage, I am not sure how one
would do this.  On our current project, I have half a meg of flash
memory connected over the SPI bus to maintain multiple versions of
firmware (using the Atmega2560, with 256k of ROM space).

I had to write a bunch of PC routines to dynamically generate my
firmware release, and insert the binary code of the new bootloader into
a standard firmware release.  So if I ever added a new bootloader, all I
had to do was add it into my class library, and then anyone who
requested a firmware download through my API would see this as
completely transparent.

Obviously, there was a decent amount of thought that went into this
before it was implemented, but it works rather well.

Of course, I couldn't protect the bootloader, but then again, on the
PIC, I couldn't protect a large enough area to cover the size of my
bootloader, anyhow.

Mark E. Scott, Jr.
address@hidden
AWS, Inc.
512-478-7727 x 122

-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of E.
Weddington
Sent: Monday, June 13, 2005 6:18 AM
To: Joerg Wunsch
Cc: address@hidden
Subject: Re: [avr-gcc-list] bootloader: replace bootloader with anew
bootloader

Joerg Wunsch wrote:

>Torsten Mohr <address@hidden> wrote:
>  
>
>Basically, if you want to do this, you need a bootloader that is small
>enough so two bootloaders will fit into the boot region.  That way, it
>should be possible to reprogram the inactive half of the bootloader.
>Take care to understand all the implications of programming the
>No-read-while-write (NRWW) section of the flash ROM.  As soon as your
>new half of the bootloader has been programmed successfully (and
>verified CRC or such), flip the first page of the bootloader area to
>point to the new loader.
>  
>

Something similar to this, is to have your bootloader be half or less 
than the availble bootloader area. Then, when calling the bootloader 
(which resides in the lower half of the bootloader section), the first 
thing the bootloader does is to copy itself to the upper half of the 
bootloader area, then call the bootloader copy in the upper half which 
then does the actual bootloading. The bootloading will then write new 
code from the beginning of flash all the way through the first half of 
the bootloader section, hence replacing the bootloader. Granted, if 
there is a power failure then all could be lost. And, yes, this scheme 
actually does work.

Eric




_______________________________________________
AVR-GCC-list mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list