Lpc2000

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:
>
> At 12:25 AM 4/29/2006 +0000, jayasooriah wrote:
> >--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@>
> >
> > > It really stinks of an underlying HW race
> > > condition.--- In lpc2000@yahoogroups.com, Robert Adsett
<subscriptions@...> wrote:
> >I think the kind hardware *and* software (in the supplied Bootloader)
> >problems on the LPC Family is without precedent.
> 
> I've seen worse, and I've heard that the 4 bit micros used in are much 
> worse.  At least all the problems are in the peripherals and most
have SW 
> workarounds.  Race conditions seem to have been a particular blind
spot for 
> some reason though, most of the HW problems seem to lead back to
some sort 
> of race.

I like to know if you think any other ARM licensee is worse.

> DCD/ISP is a design issue not a SW or HW bug.

I agree it is design issue.  I call it a defect in that the design
because it did not take into account of the kind requirements one user
had -- where the UART0 is operated in slave mode.

To fix this defect, one can change the software (in boot loader) or
add hardware to work around.  The extent to which people had discuss
about hardware options was what I referred to as intimidating.

> Personally I don't think the 
> ISP pin should have bee multiplexed at all but other micros do similar 
> things with similar consequences if the data sheets are not read
carefully 
> and the startup conditions fully considered.

One big difference I found in other micros whose feature the LPC seems
to emulate.  They have these features designed more completely and
have it implemented in hardware.

In the case of LPC, the boot loader firmware attempts to mimic these
features, and they have chosen the deferred design approach to leave
this in firmware for future updates.

Boot loader should be simple -- just to provide bare minimum to gain
control when there is no firmware, not to provide virtual flash
abstractions, external bus configuration or software protection.

The mistake IMO Philips did in incorporating these functions into a
boot loader is that they had to make it upgradeable (given things go
wrong as we have seen) and in the process, ended up with the situation
where it is possible to lock out the hardware by software.  I know of
no other system that does.  OTPs are different of course by design.

Having to condition analog input in order to use watchdog is a serious
design defect.  The fix is simple if it were done in the bootloader.
It is the obvious solution.  Saves having endless discussion on how to
solve this defect with yet another gate or chip.

> Despite the fact I'd like to see Philips being a little faster about 
> acknowledging bugs they do at least make the errata easily available.

Everyone does these days and through the web.  Gone are the days when
I had to chase suppliers to get the technical contact, and then have
to explain why I need the latest errata sheet for the engineering
sample I working on.

Jaya