--- In l..., riccardo ventrella
> OK Jaya,
> I'll try as you have suggested, it's more clearer now.
> Many thankx
> ----- Messaggio originale -----
> Da: jayasooriah
> A: l...
> Inviato: Mercoled4 aprile 2007, 10:33:56
> Oggetto: [lpc2000] Re: CAN bootloader
> --- In lpc2000@yahoogroups .com, riccardo ventrella
> > Many thanx Jaya,
> > so I can try to do in this way:
> > 1) the master notice the slave is going to send the firmware
> > 2) the slave enters in a loop, receives all the packets and store
> them somewhere in the high flash portion
> > 3) the slave jumps to the "update function" came within the
> image ( why have I to use a vector? I cannot simply
> function at that address, like the IAP in the flash? )
> > 4) the update function copies the image back to the address 0
> > The last point is not very clear, I mean: I can leave the code
> I have downloaded in flash, and modify the flash
address 0 to jump
> that code, or have to patch entirely the old code
with a copy paste?
> > Thanx for you patience
> > Ricky
> Hi Ricky,
> Why use a vector? I expected the code currently in flash sector 0
> will be calling the update process in the new image that is held in
> upper flash sector.
> Given the old image in flash cannot know where this update process
> stored in the new image, you need to use a known
address as either
> a vector or make sure the update procedure all your
> known address.
> As to your question relating to why copy the code and not patch the
> vector, have a think through what happens with successive updates.
> How are you going to make sure the different an update will go into
> busy sector, especially in an environment not all
boards are at the
> same update level.
In-service programming is one of those areas that on the face of it
are really simple, but which have a number of potential problems that
can cause units to be unserviceable. Trying to avoid these can lead
to overly complex designs, which in turn cause further reliability
The things to watch for are what happens when the download process
fails, the downloaded image is corrupted, power fails during the
switchover, etc. etc.
The good news is that these problems are well known and solutions
that work are readily available. See the following for one approach:
The key things with the solution are (a) a very simple
loader/initialiser block of code that never gets changed in-service
it has to be simple for that very reason, (b) dual images available
locally to run (the "backup" copy could be in high memory as you
suggest or in external EEPROM or similar, (c) some method for
identifying a corrupted image and (d) some method for determining
which image to run (e.g. version number).
Plenty of people use schemes like this and it can be made extremely
reliable. It's easy enough to implement on the LPC2xxx using IAP
calls to do the actual programming.
My main advice with whatever you do though would be to keep things
Hope this helps