Lpc2000

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

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