Lpc2000

Sorry for the delay, my email stopped sending and receiving for a while and 
by the time it was repaired yours is one of the messages that got lost.

  jayasooriah wrote:
>--- In lpc2000@yahoogroups.com, "robertadsett" <subscriptions@a...>
> > Not all of them do, in fact ST pops immediately to mind
> > as one who has done a very similar thing.
>
>If you can tell me which device in particular, I would like to look
>into it when get bored. My previous experience was with ST10 and its
>errata sheet was nothing like that for 2105 in terms of the types of
>bugs in silicon.

It's actually the 10F series I was thinking of.  Particularly the 168 and 
the STEAK algorithm which was introduced after the 167 um.. 
experience.  The ISP download for that family invokes a hidden ROM monitor 
and with the introduction of steak that same monitor was used for the flash 
support with the algorithm's invoked by a peculiar instruction sequence.

ST appear to have attempted the same thing with there own ARM 
implementation but botched it and according the rep I was speaking to 'are 
not going to fix it'.  Basically serial ISP disappeared between manual 
rev's which means you have no choice but to hook up JTAG.  Certainly having 
the bootloader in flash rather than it what appears to have been masked ROM 
would have been a boon for ST.

> >I can understand your security concerns even if I don't share
> >them but your angst over them not exposing the flash programming
> >algorithm seems to be overdone.
>
>Off top of my head:
>
>1/ The entire on-chip flash can be destroyed by scribbling over the
>just one location in memory with some random value. [PLLs and WDs
>incorporate feed sequences, but this self destruct sequence has none.]

That would be a good thing to have I agree but I have certainly run into 
chips with much more destructive software failure modes.  Some power chips 
that allow both high side and low sides to come on simultaneously as a for 
instance.

>2/ The sector bit maps are all over the place. In the case of 2105
>its 16 sectors are mapped to the top and bottom 8 bits, leaving out 16
>bits in the middle. [The product appears to be in its infant stages
>of development in relation to maturity of design.]

I don't see how that's of much concern to the end user.  That presumably is 
also a good reason to hide the details behind an abstracted interface.

<snip>

>About 10% of LPC2105 parts with bootloader versions prior to 1.52 did
>fail in the field according to Philips. One wonders what happened in
>the field resulting in Philips stating this in the errata sheet.

 From my observations the problem was parts that failed to program (not 
ones that self destructed).  And unlike ST they were able to fix the 
problem  Both approaches have issues and more protection may well be 
advised for the Philips flash registers but it does strike me that the 
issue as far as the bootloader and IAP goes the issue it not the SW but the 
vulnerability of the flash registers

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
http://www.aeolusdevelopment.com/