Lpc2000

Here's a thought, how about reading sector zero into RAM and erasing 
the location corresponding to location 0x14 in flash (valid code 
ID).  Then erase sector zero and write back the modified version from 
RAM.  That way you have cleared the valid code ID and the next reset 
will result in entry into ISP mode.

Rich



--- In lpc2000@yahoogroups.com, Shannon Holland <holland@l...> wrote:
> 
> On Wednesday, July 7, 2004, at 08:30 PM, Robert Adsett wrote:
> 
> > At 07:47 PM 7/7/04 -0700, you wrote:
> >> It would be nice if Philips provided a reliable (as in supported)
> >> mechanism to get back into the bootloader from user code.
> >
> > Not to pick on you in particular, but this seems an awful lot of 
angst 
> > over
> > bringing out one more connection.  If you are going to allow ISP 
after
> > potting you have bring out a minimum of 3 signals anyway (TxD, 
RxD and
> > Gnd), 5 if you provide power and control the reset.  Adding 1 to 
> > control
> > P0.14 really doesn't seem like a big deal.  Actually the only 
element 
> > that
> > comes to mind is if you are reusing a connector with predefined 
> > meanings
> > and can't reuse an existing pin definition for programming.
> >
> > In addition, it is possible to get into a situation where the 
part is
> > partially programmed and therefore won't enter ISP mode 
automatically 
> > but
> > there isn't a valid user program to force a shift to ISP mode.  
If 
> > P0.14 is
> > not brought out in some fashion then any boards that get stuck 
here 
> > will
> > have to be tossed.
> >
> > I think if you need to be able to program parts reliably w/o 
using 
> > P0.14
> > you will need to devote the first sector to a code that is never 
> > erased and
> > provides a way to program the remaining 14 sectors with the 
application
> > code.  The first sector might also provide other support code 
(maybe
> > diagnostics, a way to initialize the hardware to a good, safe 
start
> > condition etc...
> >
> >
> 
> I would agree! I have no angst on this issue, it just seemed like 
it 
> might be a useful thing which wouldn't be that hard to do from the 
> bootloader side. In my particular case I have a separate chip 
driving 
> the programming - I'm using a TUSB3410 to provide a usb->uart 
interface 
> and then driving P0.14 and RST with two of it's GPIO's. So far it 
works 
> well.
> 
> The LPC210x parts are pretty tight on GPIO, in that sense a 
> non-external bootloader entry would be nice (except that you would 
> still have to guarantee logic high on reset), but as you point out 
it 
> would only work if you can get to it reliably (or are willing to 
accept 
> some amount of un-reliablity). If you did devote the first sector 
> towards an additional bootloader you could just have it do diags 
and 
> then call the philips bootloader for programming. Still seems like 
a 
> lot of work.
> 
> Shannon