|
I'm trying to setup a failproof flash update method, so an
interrupted and incomplete flash update would not force to open the unit and insert a jumper etc. We did thuch things with other controllers, by using one sector as a fixed service monitor, which was always called by reyset, and then passed operation to the application, after the application had been proved valid by checking some CRC or so. This service monitor was never deleted, and allowed for recover, if something went wrong during flash update procedure. Now the LPC family incorporates something similar with the Flash Boot Loader, but unfortunately this original Boot Loader is restricted to the serial port, which is not available on top of every box we do. So we came to the point, that replacing this Flash Boot Loader might be the way out. Did anybody else try this? Is it possible, are there any restrictions? Thanks, Andreas |
|
|
LPC2119 Replacing Flash Boot Loader
Started by ●July 11, 2004
Reply by ●July 11, 20042004-07-11
|
At 08:48 AM 7/11/04 +0000, you wrote: >So we came to the point, that replacing this Flash Boot Loader might >be the way out. >Did anybody else try this? >Is it possible, are there any restrictions? The biggest restriction is that it is protected. The second is that it contains the IAP and ISP support so even if you could erase it you would then have to somehow reverse engineer the flash algorithm (and there is no reason to believe that will stay constant over silicon revs). There has been a rumor that someone erased the boot block accidentally but there have been no details so I don't believe it. You should read back through the recent discussions "Activating Boot Loader..." and "Loading hexes..." I think we came up with four basic techniques. 1- (probably the most foolproof), Bring P0.14 (and serial port) out to a connector These could be to a set of reserved pins or a reserved connector. It's not as if d-subs are expensive. Alternatively if you want to protect the interface you could place a standard ISP header in the box. 2- As you suggested reserve the first sector as a utility block and place basic support routines and a program utility. These are slightly more vulnerable but not much. And of course a lot of people have written such utilities. 3- Add a small micro as a monitor chip to monitor the incoming data and switch the micro to programming mode. 4- erase the first sector so that the micro will automatically enter ISP mode on the next reset. Probably the most vulnerable of the 4 to badly timed resets or power glitches (also programming errors) but with careful programming the window of vulnerability should be reduced to quite a small one. I don't know of anyone doing 3 or 4 yet. I would like to hear if anyone does and what their experience is. If you are wanting to use something other than the serial port (or JTAG) then I think your only reasonable approaches are either 2 or 3 (Imagine using a LPC2104 to monitor an incoming communication line and on a magic sequence resetting the application LPC , decrypting the incoming data stream and using the standard ISP techniques to program the application LPC ;) I would normally prefer #1. The only argument I've heard against it that makes sense to me is for an application where an erased micro leaves behind potentially valuable information. The other case I've had experience with is where a unprogrammed or partially programmed micro may be dangerous. In that case though you usually want to do the programming in a more controlled environment and it probably makes sense to do that as a factory return. Someone has said they ran into a problem with people making bad cables and then the unit didn't operate but I don't see that as peculiar to ISP. Pin headers and d-subs aren't particularly expensive and even if you are in an environment that required a sealed or ruggedized connector you can often add a pin or two w/o much cost increment. Robert " 'Freedom' has no meaning of itself. There are always restrictions, be they legal, genetic, or physical. If you don't believe me, try to chew a radio signal. " Kelvin Throop, III |
