Lpc2000

> 1/  The coding of the flash programming algorithm in the boot loader
> unreliable because: a) it depends on wait loops rather than polling the
> flash controller status register; and b) it requires clock frequency to be
> passed as a run-time argument.

I believe jasoorah is not the first person on this group to have found
that wrong crystal freq's in the isp application can create dead
parts, or at least bad data in flash.  I recall several posts long
before the CRP debate, though I'm too lazy to search for them.  I seem
to recal they involved 2104/5/6 parts, so there is a possibility that
this has been repaired in later parts like the 2148 and 2101/2/3.

I, for one, had origonally assumed the presence of a crystal-freq in
the isp app was just for setting baud-rate dividers appropriately,
though in hindsight, it's obvious that that's needed in the device,
not the pc.  This news makes one very cautious, and I don't hesitate
to say that a bootloader requiring a human to type in the crystal freq
to program memory is worthy of being disparaged, in my opinion.  Which
is not to say that I've seen conclusive proof that this is the case,
either from this group, or on my own.  This is one that seems to me
philips could lay to rest easialy - if the crystal freq is not used
for timing memory programming, they can say so.  I don't see why the
snip of code uilizing the xtal freq couldn't be published.

For the record: I have a 2148 board with a 12MHz xtal, and 2106 &
2103's with a 14.xxxMHz, and I'm always forgetting to change the
crystal freq in the isp app.  Aside from giving me heart-failure every
time I do it, I have not yet trashed a part, but then I'd say I've
been through less than 50 isp cycles with all my boards put together,
and those two frequencies are only 17% apart as well.

Steve