Lpc2000

Robert Adsett wrote:
> I don't think that's any more effective than simply erasing the first 
> sector, although it does give it a longer period to run between being made 
> invalid and actually requiring a reload.  It doesn't get rid of the basic 
> vulnerability of trying to set up ISP w/o access to P0.14 though.  If you 
> only get partway through reloading the flash (say you erase the device and 
> program the first two sectors) you end up with a device with an invalid 
> program that 'thinks' it has a valid program.  You can't force it into ISP 
> mode in hardware and there isn't enough program left to shift it into ISP 
> mode  in software.

You could reduce the failure window by doing a checksum of the entire 
flash at the beginning of the init code in the first sector, and erasing 
the first sector again if it fails (of course you'd have to add a 
checksum word to the end of your flash image for this to work).

> Add a small cheap micro to snoop on the incoming (RxD) serial line of the 
> LPC.  When it detects some unique sequence that is not valid for the 
> program in the LPC it asserts the reset line and pulls P0.14 low.  It can 
> then deassert the reset line and voila you are in ISP mode.  On reset (or 
> another unique sequence) it simply lets the reset and P0.14 lines float 
> free again.

Good idea, especially if the simple uC can perform some other useful 
task as well. My current LPC2100 design has a couple of PIC12C508s in it 
performing various simple tasks with fairly tight timing requirements 
that in the past might have used a bunch of R/C timers and TTL logic 
chips. They interface to the the LPC with a home-brewed 1 wire 
communication protocol.

-- 
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer