Lpc2000

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..."
----------------------------------------------------