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