LPC2119 Replacing Flash Boot Loader

Started by alipowsky July 11, 2004
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?


An Engineer's Guide to the LPC2100 Series

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.


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