Lpc2000

I am building a product that will be encapulated in a blob of epoxy.

I live in the real world so I know that with any new product firmware 
upgrades are almost inevitable. These can be loaded into
a LPC2106 PROVIDED that the P0.14 can be accessed Tricky from inside the 
blob.

Is it possible to to activate the code that does the boot loading from 
within my old program, ie jump to some location like we do for IAP 
programming

Thanks

Owen Mooney

At 09:40 AM 7/8/04 +1200, you wrote:
>I am building a product that will be encapulated in a blob of epoxy.
>
>I live in the real world so I know that with any new product firmware
>upgrades are almost inevitable. These can be loaded into
>a LPC2106 PROVIDED that the P0.14 can be accessed Tricky from inside the
>blob.

Well  you are bringing out the serial lines already so that would be just 
one extra pin on your connector.  However, I presume there are reasons you 
are reluctant to do that.


>Is it possible to to activate the code that does the boot loading from
>within my old program, ie jump to some location like we do for IAP
>programming

There was an earlier thread (loading hex-es) where we speculated about 
simply clearing the first area of flash and then resetting to induce the 
LPC to enter program mode as if it were a new (or misprogrammed) 
part.  Since no one has done this yet AFAIK you should test this before 
committing to using it with encapsulated boards.  It does look like a 
reasonable idea though.

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

Owen 

Try this sequence from your program which needs to be updated.

Make bootloader vectors visible 
Write 0x0 to the MEMMAP (0xE01FC040)

Select P0.14 as output. You may want to do a read-modify-write here.
Write 0x4000 to the IODIR (0xE0028008)

Make P0.14 Low
Write 0x4000 to the IOCLR (0xE002800C)

Branch to address 0x0 in ARM mode.

This should invoke the bootloader in ISP mode. Update the code via 
serial ISP and the next reset should execute the new code.

Hope this works for you.

Tom


--- In lpc2000@yahoogroups.com, Owen Mooney <ojm@s...> wrote:
> I am building a product that will be encapulated in a blob of epoxy.
> 
> I live in the real world so I know that with any new product 
firmware 
> upgrades are almost inevitable. These can be loaded into
> a LPC2106 PROVIDED that the P0.14 can be accessed Tricky from 
inside the 
> blob.
> 
> Is it possible to to activate the code that does the boot loading 
from 

> within my old program, ie jump to some location like we do for IAP 
> programming
> 
> Thanks
> 
> Owen Mooney

Hmmm,
   Branching to 0x00 is not the same as a reset, IOW you will not end 
up in the bootloader that samples P0.14 and enters ISP mode etc.

Rich

--- In lpc2000@yahoogroups.com, "lpc2100" <lpc2100@y...> wrote:
> Owen 
> 
> Try this sequence from your program which needs to be updated.
> 
> Make bootloader vectors visible 
> Write 0x0 to the MEMMAP (0xE01FC040)
> 
> Select P0.14 as output. You may want to do a read-modify-write here.
> Write 0x4000 to the IODIR (0xE0028008)
> 
> Make P0.14 Low
> Write 0x4000 to the IOCLR (0xE002800C)
> 
> Branch to address 0x0 in ARM mode.
> 
> This should invoke the bootloader in ISP mode. Update the code via 
> serial ISP and the next reset should execute the new code.
> 
> Hope this works for you.
> 
> Tom
> 
> 
> --- In lpc2000@yahoogroups.com, Owen Mooney <ojm@s...> wrote:
> > I am building a product that will be encapulated in a blob of 
epoxy.
> > 
> > I live in the real world so I know that with any new product 
> firmware 
> > upgrades are almost inevitable. These can be loaded into
> > a LPC2106 PROVIDED that the P0.14 can be accessed Tricky from 
> inside the 
> > blob.
> > 
> > Is it possible to to activate the code that does the boot loading 
> from 
> > within my old program, ie jump to some location like we do for 
IAP 

> > programming
> > 
> > Thanks
> > 
> > Owen Mooney

How about implementing the watchdog? That's closest
thing to a hardware reset (without pressing the
switch). 

You might run into a few issues using the watchdog
timer, especially if it's an lpc2114 or lower...I'm
not sure which lpc has the improved version of
watchdog timer though. 

--- Richard <richas@...> wrote:
> Hmmm,
>    Branching to 0x00 is not the same as a reset, IOW
> you will not end 
> up in the bootloader that samples P0.14 and enters
> ISP mode etc.
> 
> Rich
> 
> --- In lpc2000@yahoogroups.com, "lpc2100"
> <lpc2100@y...> wrote:
> > Owen 
> > 
> > Try this sequence from your program which needs to
> be updated.
> > 
> > Make bootloader vectors visible 
> > Write 0x0 to the MEMMAP (0xE01FC040)
> > 
> > Select P0.14 as output. You may want to do a
> read-modify-write here.
> > Write 0x4000 to the IODIR (0xE0028008)
> > 
> > Make P0.14 Low
> > Write 0x4000 to the IOCLR (0xE002800C)
> > 
> > Branch to address 0x0 in ARM mode.
> > 
> > This should invoke the bootloader in ISP mode.
> Update the code via 
> > serial ISP and the next reset should execute the
> new code.
> > 
> > Hope this works for you.
> > 
> > Tom
> > 
> > 
> > --- In lpc2000@yahoogroups.com, Owen Mooney
> <ojm@s...> wrote:
> > > I am building a product that will be encapulated
> in a blob of 
> epoxy.
> > > 
> > > I live in the real world so I know that with any
> new product 
> > firmware 
> > > upgrades are almost inevitable. These can be
> loaded into
> > > a LPC2106 PROVIDED that the P0.14 can be
> accessed Tricky from 
> > inside the 
> > > blob.
> > > 
> > > Is it possible to to activate the code that does
> the boot loading 
> > from 
> > > within my old program, ie jump to some location
> like we do for 
> IAP 
> > > programming
> > > 
> > > Thanks
> > > 
> > > Owen Mooney
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

The idea here is to fool the bootloader when it samples P0.14. If 
serial port 0 is used in the application then it also needs to clear 
the bit 2-3 of PINSEL0 and bits 1 of the IODIR register.

I have verified the concept on the Ashling board running ledtest 
image.

--- In lpc2000@yahoogroups.com, "Richard" <richas@y...> wrote:
> Hmmm,
>    Branching to 0x00 is not the same as a reset, IOW you will not 
end 
> up in the bootloader that samples P0.14 and enters ISP mode etc.
> 
> Rich
> 
> --- In lpc2000@yahoogroups.com, "lpc2100" <lpc2100@y...> wrote:
> > Owen 
> > 
> > Try this sequence from your program which needs to be updated.
> > 
> > Make bootloader vectors visible 
> > Write 0x0 to the MEMMAP (0xE01FC040)
> > 
> > Select P0.14 as output. You may want to do a read-modify-write 
here.
> > Write 0x4000 to the IODIR (0xE0028008)
> > 
> > Make P0.14 Low
> > Write 0x4000 to the IOCLR (0xE002800C)
> > 
> > Branch to address 0x0 in ARM mode.
> > 
> > This should invoke the bootloader in ISP mode. Update the code 
via 
> > serial ISP and the next reset should execute the new code.
> > 
> > Hope this works for you.
> > 
> > Tom
> > 
> > 
> > --- In lpc2000@yahoogroups.com, Owen Mooney <ojm@s...> wrote:
> > > I am building a product that will be encapulated in a blob of 
> epoxy.
> > > 
> > > I live in the real world so I know that with any new product 
> > firmware 
> > > upgrades are almost inevitable. These can be loaded into
> > > a LPC2106 PROVIDED that the P0.14 can be accessed Tricky from 
> > inside the 
> > > blob.
> > > 
> > > Is it possible to to activate the code that does the boot 
loading 

> > from 
> > > within my old program, ie jump to some location like we do for 
> IAP 
> > > programming
> > > 
> > > Thanks
> > > 
> > > Owen Mooney

The watchdog reset won't work because the bootloader skips P0.14 
sampling when WDTOF bit is set as indicated in the bootloader 
flowchart.

--- In lpc2000@yahoogroups.com, Leighton Rowe <leightonsrowe@y...> 
wrote:

> How about implementing the watchdog? That's closest
> thing to a hardware reset (without pressing the
> switch). 
> 
> You might run into a few issues using the watchdog
> timer, especially if it's an lpc2114 or lower...I'm
> not sure which lpc has the improved version of
> watchdog timer though. 
> 
> --- Richard <richas@y...> wrote:
> > Hmmm,
> >    Branching to 0x00 is not the same as a reset, IOW
> > you will not end 
> > up in the bootloader that samples P0.14 and enters
> > ISP mode etc.
> > 
> > Rich
> > 
> > --- In lpc2000@yahoogroups.com, "lpc2100"
> > <lpc2100@y...> wrote:
> > > Owen 
> > > 
> > > Try this sequence from your program which needs to
> > be updated.
> > > 
> > > Make bootloader vectors visible 
> > > Write 0x0 to the MEMMAP (0xE01FC040)
> > > 
> > > Select P0.14 as output. You may want to do a
> > read-modify-write here.
> > > Write 0x4000 to the IODIR (0xE0028008)
> > > 
> > > Make P0.14 Low
> > > Write 0x4000 to the IOCLR (0xE002800C)
> > > 
> > > Branch to address 0x0 in ARM mode.
> > > 
> > > This should invoke the bootloader in ISP mode.
> > Update the code via 
> > > serial ISP and the next reset should execute the
> > new code.
> > > 
> > > Hope this works for you.
> > > 
> > > Tom
> > > 
> > > 
> > > --- In lpc2000@yahoogroups.com, Owen Mooney
> > <ojm@s...> wrote:
> > > > I am building a product that will be encapulated
> > in a blob of 
> > epoxy.
> > > > 
> > > > I live in the real world so I know that with any
> > new product 
> > > firmware 
> > > > upgrades are almost inevitable. These can be
> > loaded into
> > > > a LPC2106 PROVIDED that the P0.14 can be
> > accessed Tricky from 
> > > inside the 
> > > > blob.
> > > > 
> > > > Is it possible to to activate the code that does
> > the boot loading 
> > > from 
> > > > within my old program, ie jump to some location
> > like we do for 
> > IAP 
> > > > programming
> > > > 
> > > > Thanks
> > > > 
> > > > Owen Mooney
> > 
> > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com

On Jul 7, 2004, at 7:37 PM, lpc2100 wrote:

> The idea here is to fool the bootloader when it samples P0.14. If
> serial port 0 is used in the application then it also needs to clear
> the bit 2-3 of PINSEL0 and bits 1 of the IODIR register.
>
> I have verified the concept on the Ashling board running ledtest
> image.
>

Did you remap memory to put the bootloader back at address 0, or 
something else? Only thing I would be concerned about is if Philips 
changed the bootloader so that it reset the iodir on P0.14.

It would be nice if Philips provided a reliable (as in supported) 
mechanism to get back into the bootloader from user code.

Shannon

At 02:37 AM 7/8/04 +0000, you wrote:
>The idea here is to fool the bootloader when it samples P0.14. If
>serial port 0 is used in the application then it also needs to clear
>the bit 2-3 of PINSEL0 and bits 1 of the IODIR register.
>
>I have verified the concept on the Ashling board running ledtest

Sorry, I've lost track somewhere here.  What, exactly, did you verify?

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

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...

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

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

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

> Sorry, I've lost track somewhere here.  What, exactly, did you 
verify?

Re-entry in to bootloader ISP without touching the P0.14 pin when the 
device already had a valid user code.

re_enter_bootloader_isp
{
    volatile unsigned long * memmap;
    volatile unsigned long * ioclr;
    volatile unsigned long * iodir;
    volatile unsigned long * pinsel0;
    void (*bootloader_entry)(void);
    unsigned long temp;

    memmap  = (volatile unsigned long *)0xE01FC040;
    ioclr   = (volatile unsigned long *)0xE002800C;
    iodir   = (volatile unsigned long *)0xE0028008;
    pinsel0 = (volatile unsigned long *)0xE002C000;

    *memmap = 0x0;

    temp = *pinsel0;
    *pinsel0 = temp & 0xFFFFFFF3;

    temp = *iodir;
    temp = temp | 0x4000;
    temp = temp & 0xFFFFFFFD;
    *iodir = temp;

    *ioclr = 0x4000;

    bootloader_entry = (void (*)(void))(0x0);
    bootloader_entry();
}

At 06:39 PM 7/8/04 +0000, you wrote:
> > Sorry, I've lost track somewhere here.  What, exactly, did you
>verify?
>
>Re-entry in to bootloader ISP without touching the P0.14 pin when the
>device already had a valid user code.

<snip>
OK, that's clearer.  Neat parlour trick.  I don't know whether to be amused 
or distressed that it works.  It does open up a whole new class of symptoms 
for null function pointer bugs :)


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

At 06:20 PM 7/8/04 +0000, you wrote:
>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.

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.

Just to contribute my own angst to the subject.  If you really are in a 
situation where you can't afford the extra pin then something like the 
following might 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.

That doesn't require any more care on P0.14 than it already requires and 
the micro needed should be relatively inexpensive.  Still seems like a lot 
of work to avoid a pin though.

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

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

At 09:19 PM 7/8/04 +0100, you wrote:
>Robert Adsett wrote:
> > 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.
The one that occurred to me is, since it's already hooked up to the the 
reset line, it could make a pretty sophisticated application specific 
watchdog timer.

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

You're getting me worried..

I also have to support ISP without P0.14 - absolutely no choice and 
not an issue of saving a pin - it is the fact that the chip is in a 
sealed and protected casing containing a high security key (which 
gets wiped out if the case is opened, drilled into, sujected to to 
high/low temperatures etc. It is too dangerous to allow the ISP line 
to be accessible from outside otherwise some smart-alec will use it 
to load a program to simply read and send out the secret key.

First I was monitoring the Rx line using a PIC but it got too messy 
and space requirements made me remove it and connect the ISP line to 
VDD - the solution being to request the processor to go to download 
mode before which it also destroys the key information and then 
deletes the first sector. Turning one and off power then 
automatically enters the ISP mode and new code can be loaded (of 
course a new key will also have to be loaded afterwards, but that is 
what we want - only when the key has been loaded is the issue safely 
sensitive again..)

I thought that the check sum over the interrupt vectors was 
calculated and written automatically by the device at the end of an 
ISP download. Is there evidence that this technique can fail if the 
ISP download is aborted before it has completed? (valid interrupt 
vector check sum without any code). Perhaps we should experiment a 
little to avoid getting caught out.

Any expert out there who know the exact answer????

Cherrs

Mark Butcher
www.mjbc.ch


Replying to the comment...

> >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.
> 
> 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.
>

mjbcswitzerland wrote:
> I thought that the check sum over the interrupt vectors was 
> calculated and written automatically by the device at the end of an 
> ISP download.

No, the ISP uploader program calculates the checksum before uploading 
the code to the device. Another way of reducing the risk of a partial 
upload with a valid vector checksum might be to use a modified version 
of lpc21isp that uploads the first sector last.

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

Now there is a reason not to bring a pin out.

At 09:47 PM 7/8/04 +0000, you wrote:
>I thought that the check sum over the interrupt vectors was
>calculated and written automatically by the device at the end of an
>ISP download. Is there evidence that this technique can fail if the
>ISP download is aborted before it has completed? (valid interrupt
>vector check sum without any code). Perhaps we should experiment a
>little to avoid getting caught out.

I've already experienced it (not deliberately).  An interrupted download 
must be re-programed by pulling P0.14 low, otherwise the LPC attempts to 
run whatever portion of the application is already programmed in the 
chip.  I've only noted this because the Philips download program can't 
communicate with the chip to perform a download unless P0.14 is pulled low 
and the chip is reset.

The checksum is definitely calculated by the download software not the 
LPC.  The ISP support on the LPC simply writes arbitrary blocks at given 
locations, it has no concept of a process with a beginning and an end.  The 
order of writes depends on the download software.  From what I remember of 
reviewing the lpc2isp software it calculates the checksum at the beginning 
(seems straight forward enough) and then simply programs the sectors in 
sequence.

 From the visible behaviour it looks like Philips program does the same but 
I'd have to snoop the serial line to be sure.  You could write a custom 
program that programmed the first sector last.  That would reduce the 
window, especially if the block containing the checksum was the last to be 
written.  I'm not sure even that absolutely eliminates the possibility of 
ending up with a problem but the probability becomes quite small.

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

Thanks for the various replys on this and I will try them.

It may seem like angst over an external pin, BUT I have made one product 
(with motorola chip) which used an external pin to force it into boot 
loader mode. I had one customer who kept sending units back for repair 
as someone in his organisation had a misswired serial lead!!!!!

His fault, BUT who gets the blame for an unreliable product.

I never had that problems with another product with software activated 
flashing code.

Thanks

Owen

At 04:22 PM 7/9/04 +1200, you wrote:
>It may seem like angst over an external pin, BUT I have made one product
>(with motorola chip) which used an external pin to force it into boot
>loader mode. I had one customer who kept sending units back for repair
>as someone in his organisation had a misswired serial lead!!!!!

You mean that the unit was actually erased or programmed?  All the serial 
downloads I've seen require a reasonably lengthy sequence before you could 
do either.  It's rather hard to envision getting that far simply because of 
a cable problem.

If it was simply a matter of not communicating, then I have run into that 
as an enduser.  But it doesn't take the addition of a programming line to 
cause that.  Serial breakout boxes exist for a reason you know :)

Of course all the pins have predefined and used functionality for a serial 
9-pin d-sub which makes an off the shelf cable more of a potential problem, 
but the 25 pin has a number of pins that are not usually used (or you could 
us some other connector entirely).

>His fault, BUT who gets the blame for an unreliable product.

Well if simply hooking up the pin caused the unit to cease functioning 
until re-programmed I'd have concerns about it's functioning in the real 
world.  But if just means they don't operate until the cable is 
corrected?  A lot of equipment won't operate correctly with a bad cable.

>I never had that problems with another product with software activated
>flashing code.

The biggest problems I've seen or had to worry about with software 
activated code occur when the activation code is part of the downloaded 
image and then you have to worry about
- what happens when the download is interrupted before completion
- what happens if there is a bug in the new image that doesn't allow 
another download to occur.  Hopefully through test and review makes this 
possibility unlikely but I seem to remember stories of products this has 
occured to (I seem to remember compuserve or AOL having a problem like this 
many moons ago)

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