Updating firmware using ISP GO command?

Started by Srdan Suka March 9, 2006
Hi everyone!

I am using LPC2103 in my project. LPC is connected to server using
RS485 interface (Semi-duplex). Also I have EEPROM memory connected to 
LPC. 
I would like to do this if it is possible:

1. Using my resident LPC firmware, load new firmware to EEPROM memory.
2. Load a small program into Flash into first available sector
   (this program I would like to use to copy new firmware from
    EEPROM to Flash over the existing firmware).

Is it possible to use ISP GO command to execute "Copy proggram" from
Flash to start copying firmware from EEPROM to flash memory.
What will happen it copy process fails and I overwrite firmware at
0x0000 0000 address?
Can I "tell" the bootloader alwayws to start the "Copy
program" unless I 
"tell" it that the updating is finishead and the main firmware should
be started?

Has anyone tried this? 

Thanks :)

Srdan
	

An Engineer's Guide to the LPC2100 Series

I implemented a second stage bootloader in the first flash sector that 
is able to update the flash via a FTDI FT245 usb link. The bootloader 
checks a signature (a CRC is also possible) and if this is correct, it 
starts the program from the second flash sector. The program can jump to 
a fixed address (immediately after the exception vectors) to erase the 
program and start an update procedure.

If the update fails, my own bootloader in the first sector will not 
start the program in the second sector because of an incorrect signature 
or crc and it will run in update mode until a correct program is uploaded.

A disadvantage is that you need to relocate the exception vectors to ram 
or use the fixed exception vector table from the bootloader. Another 
disadvantage is (at least with the keil ide) is that the debugger / jtag 
flash programmer does not know how to handle a program that does not use 
sector 0 which I solved by always including the bootloader code in the 
ide project.

Regards,
Richard.
	Srdan Suka wrote:
> Hi everyone!
>
> I am using LPC2103 in my project. LPC is connected to server using
> RS485 interface (Semi-duplex). Also I have EEPROM memory connected to
> LPC.
> I would like to do this if it is possible:
>
> 1. Using my resident LPC firmware, load new firmware to EEPROM memory.
> 2. Load a small program into Flash into first available sector
>    (this program I would like to use to copy new firmware from
>     EEPROM to Flash over the existing firmware).
>
> Is it possible to use ISP GO command to execute "Copy proggram"
from
> Flash to start copying firmware from EEPROM to flash memory.
> What will happen it copy process fails and I overwrite firmware at
> 0x0000 0000 address?
> Can I "tell" the bootloader alwayws to start the "Copy
program" unless I
> "tell" it that the updating is finishead and the main firmware
should
> be started?
>
> Has anyone tried this?
>
> Thanks :)
>
> Srdan
>
>
	
Thanks Richard

This solution sounds ok and it seems better than use
ISP commands. 
How did you solve the problem with reallocation
of exception vectors?

Thanks again,

Srdan
	--- In lpc2000@lpc2..., Richard Duits <yahoo@...> wrote:
>
> I implemented a second stage bootloader in the first flash sector that 
> is able to update the flash via a FTDI FT245 usb link. The bootloader 
> checks a signature (a CRC is also possible) and if this is correct, it 
> starts the program from the second flash sector. The program can
jump to 
> a fixed address (immediately after the exception
vectors) to erase the 
> program and start an update procedure.
> 
> If the update fails, my own bootloader in the first sector will not 
> start the program in the second sector because of an incorrect
signature 
> or crc and it will run in update mode until a
correct program is
uploaded.
> 
> A disadvantage is that you need to relocate the exception vectors to
ram 
> or use the fixed exception vector table from the
bootloader. Another 
> disadvantage is (at least with the keil ide) is that the debugger /
jtag 
> flash programmer does not know how to handle a
program that does not
use 
> sector 0 which I solved by always including the
bootloader code in the 
> ide project.
> 
> Regards,
> Richard.
> 
> 
> Srdan Suka wrote:
> > Hi everyone!
> >
> > I am using LPC2103 in my project. LPC is connected to server using
> > RS485 interface (Semi-duplex). Also I have EEPROM memory connected to
> > LPC.
> > I would like to do this if it is possible:
> >
> > 1. Using my resident LPC firmware, load new firmware to EEPROM memory.
> > 2. Load a small program into Flash into first available sector
> >    (this program I would like to use to copy new firmware from
> >     EEPROM to Flash over the existing firmware).
> >
> > Is it possible to use ISP GO command to execute "Copy
proggram" from
> > Flash to start copying firmware from EEPROM to flash memory.
> > What will happen it copy process fails and I overwrite firmware at
> > 0x0000 0000 address?
> > Can I "tell" the bootloader alwayws to start the "Copy
program"
unless I
> > "tell" it that the updating is
finishead and the main firmware should
> > be started?
> >
> > Has anyone tried this?
> >
> > Thanks :)
> >
> > Srdan
> >
> >
>
	
I only use the interrupt vector which jumps to the address read from the 
VIC and the SWI vector, which jumps to a fixed address. But you also 
copy your vectors to RAM and use the MEMMAP register to remap the 
interrupt vectors to RAM. Read the "MEMORY MAPPING CONTROL" section in

the user manual to see how this works.

Richard.
	Srdan Suka wrote:
> Thanks Richard
>
> This solution sounds ok and it seems better than use
> ISP commands.
> How did you solve the problem with reallocation
> of exception vectors?
>
> Thanks again,
>
> Srdan
>
>
>
> --- In lpc2000@lpc2..., Richard Duits <yahoo@...> wrote:
> >
> > I implemented a second stage bootloader in the first flash sector that
> > is able to update the flash via a FTDI FT245 usb link. The bootloader
> > checks a signature (a CRC is also possible) and if this is correct, it
> > starts the program from the second flash sector. The program can
> jump to
> > a fixed address (immediately after the exception vectors) to erase the
> > program and start an update procedure.
> >
> > If the update fails, my own bootloader in the first sector will not
> > start the program in the second sector because of an incorrect
> signature
> > or crc and it will run in update mode until a correct program is
> uploaded.
> >
> > A disadvantage is that you need to relocate the exception vectors to
> ram
> > or use the fixed exception vector table from the bootloader. Another
> > disadvantage is (at least with the keil ide) is that the debugger /
> jtag
> > flash programmer does not know how to handle a program that does not
> use
> > sector 0 which I solved by always including the bootloader code in the
> > ide project.
> >
> > Regards,
> > Richard.
> >
> >
> > Srdan Suka wrote:
> > > Hi everyone!
> > >
> > > I am using LPC2103 in my project. LPC is connected to server
using
> > > RS485 interface (Semi-duplex). Also I have EEPROM memory
connected to
> > > LPC.
> > > I would like to do this if it is possible:
> > >
> > > 1. Using my resident LPC firmware, load new firmware to EEPROM
memory.
> > > 2. Load a small program into Flash into first available sector
> > >    (this program I would like to use to copy new firmware from
> > >     EEPROM to Flash over the existing firmware).
> > >
> > > Is it possible to use ISP GO command to execute "Copy
proggram" from
> > > Flash to start copying firmware from EEPROM to flash memory.
> > > What will happen it copy process fails and I overwrite firmware
at
> > > 0x0000 0000 address?
> > > Can I "tell" the bootloader alwayws to start the
"Copy program"
> unless I
> > > "tell" it that the updating is finishead and the main
firmware should
> > > be started?
> > >
> > > Has anyone tried this?
> > >
> > > Thanks :)
> > >
> > > Srdan
> > >
> > >
> >
>
>
>
>
>
>
> SPONSORED LINKS
> Microcontrollers 
>
<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=mfaAujKZXA2Z_vxre9sGnQ>

> 	Microprocessor 
>
<http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=9jjd2D3GOLIESVQssLmLsA>

> 	Intel microprocessors 
>
<http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=OMnZuqMZX95mgutt4B-tDw>

>
> Pic microcontrollers 
>
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=Malspbd0T4Rq3M4Q0nHrfw>

>
>
>
> 
> >.
>
>
> 
>
	
Is there some example code of such second stage bootloader
that you use in your project?

Thanks in advance,

Srdan

--- In lpc2000@lpc2..., Richard Duits <yahoo@...> wrote:
>
> I only use the interrupt vector which jumps to the address read from
the 
> VIC and the SWI vector, which jumps to a fixed
address. But you also 
> copy your vectors to RAM and use the MEMMAP register to remap the 
> interrupt vectors to RAM. Read the "MEMORY MAPPING CONTROL"
section in 
> the user manual to see how this works.
> 
> Richard.
> 
> 
> 
> Srdan Suka wrote:
> > Thanks Richard
> >
> > This solution sounds ok and it seems better than use
> > ISP commands.
> > How did you solve the problem with reallocation
> > of exception vectors?
> >
> > Thanks again,
> >
> > Srdan
> >
> >
> >
> > --- In lpc2000@lpc2..., Richard Duits <yahoo@> wrote:
> > >
> > > I implemented a second stage bootloader in the first flash
sector that
> > > is able to update the flash via a FTDI
FT245 usb link. The
bootloader
> > > checks a signature (a CRC is also
possible) and if this is
correct, it
> > > starts the program from the second flash
sector. The program can
> > jump to
> > > a fixed address (immediately after the exception vectors) to
erase the
> > > program and start an update procedure.
> > >
> > > If the update fails, my own bootloader in the first sector will
not
> > > start the program in the second sector because of an incorrect
> > signature
> > > or crc and it will run in update mode until a correct program is
> > uploaded.
> > >
> > > A disadvantage is that you need to relocate the exception vectors
to
> > ram
> > > or use the fixed exception vector table from the bootloader.
Another
> > > disadvantage is (at least with the keil ide) is that the debugger
/
> > jtag
> > > flash programmer does not know how to handle a program that does
not
> > use
> > > sector 0 which I solved by always including the bootloader code
in the
> > > ide project.
> > >
> > > Regards,
> > > Richard.
> > >
> > >
> > > Srdan Suka wrote:
> > > > Hi everyone!
> > > >
> > > > I am using LPC2103 in my project. LPC is connected to server
using
> > > > RS485 interface (Semi-duplex). Also I have EEPROM memory
connected to
> > > > LPC.
> > > > I would like to do this if it is possible:
> > > >
> > > > 1. Using my resident LPC firmware, load new firmware to
EEPROM
memory.
> > > > 2. Load a small program into Flash
into first available sector
> > > >    (this program I would like to use to copy new firmware
from
> > > >     EEPROM to Flash over the existing firmware).
> > > >
> > > > Is it possible to use ISP GO command to execute "Copy
proggram" from
> > > > Flash to start copying firmware
from EEPROM to flash memory.
> > > > What will happen it copy process fails and I overwrite
firmware at
> > > > 0x0000 0000 address?
> > > > Can I "tell" the bootloader alwayws to start the
"Copy program"
> > unless I
> > > > "tell" it that the updating is finishead and the
main firmware
should
> > > > be started?
> > > >
> > > > Has anyone tried this?
> > > >
> > > > Thanks :)
> > > >
> > > > Srdan
> > > >
> > > >
> > >
> >
> >
> >
> >
> >
> >
> > SPONSORED LINKS
> > Microcontrollers 
> >
<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=mfaAujKZXA2Z_vxre9sGnQ>

> > 	Microprocessor 
> >
<http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=9jjd2D3GOLIESVQssLmLsA>

> > 	Intel microprocessors 
> >
<http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=OMnZuqMZX95mgutt4B-tDw>

> >
> > Pic microcontrollers 
> >
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=Malspbd0T4Rq3M4Q0nHrfw>

> >
> >
> >
> >

> > >.
> >
> >
> >

> >
>
	
I cannot release the code I've written (because my boss won't let me). 
But it is that complicated. I implemented the first version in just a 
few hours. You can start with an IAP example that is probably somewhere 
in the files section of the LPC2000 group. Add your own code to 
communicate with your PC update program. Then add the code to jump to 
the second flash sector if the CRC is ok and you are done.

Richard.
	Srdan Suka wrote:
> Is there some example code of such second stage
bootloader
> that you use in your project?
>
> Thanks in advance,
>
> Srdan
>
> --- In lpc2000@lpc2..., Richard Duits <yahoo@...> wrote:
> >
> > I only use the interrupt vector which jumps to the address read from
> the
> > VIC and the SWI vector, which jumps to a fixed address. But you also
> > copy your vectors to RAM and use the MEMMAP register to remap the
> > interrupt vectors to RAM. Read the "MEMORY MAPPING CONTROL"
section in
> > the user manual to see how this works.
> >
> > Richard.
> >
> >
> >
> > Srdan Suka wrote:
> > > Thanks Richard
> > >
> > > This solution sounds ok and it seems better than use
> > > ISP commands.
> > > How did you solve the problem with reallocation
> > > of exception vectors?
> > >
> > > Thanks again,
> > >
> > > Srdan
> > >
> > >
> > >
> > > --- In lpc2000@lpc2..., Richard Duits <yahoo@> wrote:
> > > >
> > > > I implemented a second stage bootloader in the first flash
> sector that
> > > > is able to update the flash via a FTDI FT245 usb link. The
> bootloader
> > > > checks a signature (a CRC is also possible) and if this is
> correct, it
> > > > starts the program from the second flash sector. The program
can
> > > jump to
> > > > a fixed address (immediately after the exception vectors) to
> erase the
> > > > program and start an update procedure.
> > > >
> > > > If the update fails, my own bootloader in the first sector
will not
> > > > start the program in the second sector because of an
incorrect
> > > signature
> > > > or crc and it will run in update mode until a correct
program is
> > > uploaded.
> > > >
> > > > A disadvantage is that you need to relocate the exception
vectors to
> > > ram
> > > > or use the fixed exception vector table from the bootloader.
Another
> > > > disadvantage is (at least with the keil ide) is that the
debugger /
> > > jtag
> > > > flash programmer does not know how to handle a program that
does not
> > > use
> > > > sector 0 which I solved by always including the bootloader
code
> in the
> > > > ide project.
> > > >
> > > > Regards,
> > > > Richard.
> > > >
> > > >
> > > > Srdan Suka wrote:
> > > > > Hi everyone!
> > > > >
> > > > > I am using LPC2103 in my project. LPC is connected to
server using
> > > > > RS485 interface (Semi-duplex). Also I have EEPROM
memory
> connected to
> > > > > LPC.
> > > > > I would like to do this if it is possible:
> > > > >
> > > > > 1. Using my resident LPC firmware, load new firmware to
EEPROM
> memory.
> > > > > 2. Load a small program into Flash into first available
sector
> > > > >    (this program I would like to use to copy new
firmware from
> > > > >     EEPROM to Flash over the existing firmware).
> > > > >
> > > > > Is it possible to use ISP GO command to execute
"Copy
> proggram" from
> > > > > Flash to start copying firmware from EEPROM to flash
memory.
> > > > > What will happen it copy process fails and I overwrite
firmware at
> > > > > 0x0000 0000 address?
> > > > > Can I "tell" the bootloader alwayws to start
the "Copy program"
> > > unless I
> > > > > "tell" it that the updating is finishead and
the main firmware
> should
> > > > > be started?
> > > > >
> > > > > Has anyone tried this?
> > > > >
> > > > > Thanks :)
> > > > >
> > > > > Srdan
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > SPONSORED LINKS
> > > Microcontrollers
> > >
>
<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=mfaAujKZXA2Z_vxre9sGnQ

>
<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=mfaAujKZXA2Z_vxre9sGnQ>>
>
> > >       Microprocessor
> > >
>
<http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=9jjd2D3GOLIESVQssLmLsA

>
<http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=9jjd2D3GOLIESVQssLmLsA>>
>
> > >       Intel microprocessors
> > >
>
<http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=OMnZuqMZX95mgutt4B-tDw

>
<http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=OMnZuqMZX95mgutt4B-tDw>>
>
> > >
> > > Pic microcontrollers
> > >
>
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=Malspbd0T4Rq3M4Q0nHrfw

>
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=Malspbd0T4Rq3M4Q0nHrfw>>
>
> > >
> > >
> > >
> > >
> 
> > > >.
> > >
> > >
> > >
> 
> > >
> >
>
>
>
>
>
>
> SPONSORED LINKS
> Microcontrollers 
>
<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=mfaAujKZXA2Z_vxre9sGnQ>

> 	Microprocessor 
>
<http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=9jjd2D3GOLIESVQssLmLsA>

> 	Intel microprocessors 
>
<http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=OMnZuqMZX95mgutt4B-tDw>

>
> Pic microcontrollers 
>
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=Malspbd0T4Rq3M4Q0nHrfw>

>
>
>
> 
> >.
>
>
> 
>
	
Richard Duits wrote:

>I implemented a second stage bootloader in the
first flash sector that 
>is able to update the flash via a FTDI FT245 usb link. The bootloader 
>checks a signature (a CRC is also possible) and if this is correct, it 
>starts the program from the second flash sector. The program can jump to 
>a fixed address (immediately after the exception vectors) to erase the 
>program and start an update procedure.
>
>If the update fails, my own bootloader in the first sector will not 
>start the program in the second sector because of an incorrect signature 
>or crc and it will run in update mode until a correct program is uploaded.
>
>A disadvantage is that you need to relocate the exception vectors to ram 
>or use the fixed exception vector table from the bootloader. Another 
>disadvantage is (at least with the keil ide) is that the debugger / jtag 
>flash programmer does not know how to handle a program that does not use 
>sector 0 which I solved by always including the bootloader code in the 
>ide project.
>
>  
>
I've done something similar.  I reserved the upper 80K of flash for use 
of a resident bootloader.  The board has two processors: LPC2106 + 
LPC2138.  Either processor may place the other into ISP programming mode 
and program the other processors' flash memory.  An integral part of 
this approach is that the SD card will always have a copy of the current 
program of each processor.  The LPC2138 bootloader knows how to read the 
SD filesystem.

To do field updates, the end-customer replaces the two binary image 
files and manually invokes the Update mode of the system.  The LPC2106 
is where the Update mode would be initiated from, that processor informs 
the LPC2138 to begin the upgrade cycle.

Once the LPC2138 is told to do a system upgrade, it reprograms the IVECT 
table (address 0) and forces a full system reset (hardware line to RESET 
circuit).  When the LPC2138 boots, it boots into the resident loader.  
The loader will now go through the process of erasing and reprogramming 
the LPC2106.  After it successfully completes that, it then reprograms 
it's main flash (all flash between the sector 0 and the resident loader 
is erased).  When the LPC2138 main program has been programmed, as the 
last thing, it will relocate the IVECT table into RAM and program sector 
0.  Then the LPC2138 forces a final system reset.

A bit complicated, but it does work.  I needed some way to keep special 
software on a laptop out of the equation.  Trouble with field personnel 
is that there is a wide disparity of technical competence when it comes 
to computers.  Also, we wanted to keep from "owning" the laptop / 
computer by installing our own programming software onto it.  From 
experience, if you give the end-user a programming tool to install on 
their Windows computer, someone will give you grief about "your software 
screwed my computer up, tell me how to fix it!".  :(

I do need to finish the bootloader scheme and have the LPC2106 processor 
conditionally reprogram the IVECT table at sector 0 of the LPC2138.  
This way, if the final step of the LPC2138 upgrade cycle fails (LPC2138 
replacing vectors at sector 0), the LPC2106 can physically force another 
cycle.  Since the two processors talk to each other over UART0, failure 
to establish a connection within a proscribed interval would trigger this..

So far, the upgrade mechanism is working ok.

Regards,

TomW
	-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------
	
Tom Walsh wrote:

>Richard Duits wrote:
>
>  
>
>>I implemented a second stage bootloader in the first flash sector that 
>>is able to update the flash via a FTDI FT245 usb link. The bootloader 
>>checks a signature (a CRC is also possible) and if this is correct, it 
>>starts the program from the second flash sector. The program can jump to

>>a fixed address (immediately after the exception vectors) to erase the 
>>program and start an update procedure.
>>
>>If the update fails, my own bootloader in the first sector will not 
>>start the program in the second sector because of an incorrect signature

>>or crc and it will run in update mode until a correct program is
uploaded.
>>
>>A disadvantage is that you need to relocate the exception vectors to ram

>>or use the fixed exception vector table from the bootloader. Another 
>>disadvantage is (at least with the keil ide) is that the debugger / jtag

>>flash programmer does not know how to handle a program that does not use

>>sector 0 which I solved by always including the bootloader code in the 
>>ide project.
>>
>> 
>>
>>    
>>
>I've done something similar.  I reserved the upper 80K of flash for use 
>of a resident bootloader.  The board has two processors: LPC2106 + 
>LPC2138.  Either processor may place the other into ISP programming mode 
>and program the other processors' flash memory.  An integral part of 
>this approach is that the SD card will always have a copy of the current 
>program of each processor.  The LPC2138 bootloader knows how to read the 
>SD filesystem.
>
>To do field updates, the end-customer replaces the two binary image 
>files and manually invokes the Update mode of the system.  The LPC2106 
>is where the Update mode would be initiated from, that processor informs 
>the LPC2138 to begin the upgrade cycle.
>
>Once the LPC2138 is told to do a system upgrade, it reprograms the IVECT 
>table (address 0) and forces a full system reset (hardware line to RESET 
>circuit).  When the LPC2138 boots, it boots into the resident loader.  
>The loader will now go through the process of erasing and reprogramming 
>the LPC2106.  After it successfully completes that, it then reprograms 
>it's main flash (all flash between the sector 0 and the resident loader 
>is erased).  When the LPC2138 main program has been programmed, as the 
>last thing, it will relocate the IVECT table into RAM and program sector 
>0.  Then the LPC2138 forces a final system reset.
>
>A bit complicated, but it does work.  I needed some way to keep special 
>software on a laptop out of the equation.  Trouble with field personnel 
>is that there is a wide disparity of technical competence when it comes 
>to computers.  Also, we wanted to keep from "owning" the laptop / 
>computer by installing our own programming software onto it.  From 
>experience, if you give the end-user a programming tool to install on 
>their Windows computer, someone will give you grief about "your
software 
>screwed my computer up, tell me how to fix it!".  :(
>
>I do need to finish the bootloader scheme and have the LPC2106 processor 
>conditionally reprogram the IVECT table at sector 0 of the LPC2138.  
>This way, if the final step of the LPC2138 upgrade cycle fails (LPC2138 
>replacing vectors at sector 0), the LPC2106 can physically force another 
>cycle.  Since the two processors talk to each other over UART0, failure 
>to establish a connection within a proscribed interval would trigger this..
>
>So far, the upgrade mechanism is working ok.
>
>  
>
Just a further note.  It would be nice if we could protect a sector so 
that it would be impossible to use the IAP commands to reprogram that 
sector.  Make it a command that is only available via the ISP to lock / 
unlock protection on a specific sector.  If IAP attempts to erase / 
write that sector, it would unconditionally fail.

Philips, add that to my wish list?

TomW
	-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------