Lpc2000

At 02:53 AM 4/29/2006 +0000, jayasooriah wrote:
>--- 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.

Who said anything about ARM licensees?  If you make a broad statement like 
the above you have to expect a response in kind.

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

Every design fails to meet some user requirement, that's one reason we have 
so many variations on the micro theme.  That doesn't make that failure a 
bug in either SW or HW.  The STR7 series fails to meet my serial ISP 
requirement for instance, even though the original user manuals indicated 
it was supported.  Now that was a bug (Now there is an argument for a flash 
based boot loader).  On the other hand the Intel 196 doesn't support serial 
ISP at all, that's not a bug.

They had to assign the pin somewhere.  No doubt they had their reasons for 
the choice they made.  No matter where they put it, it would have caused 
someone a problem.  If there is a fault here it's in the documentation.

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

Apparently you are easily intimidated and have not been around very many 
usenet discussions :)  I know of forums where this would have trailed off 
into a discussion of how few transistors you could do it in.

And I still don't consider this a defect.

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

Even if I were to agree with all of the above it doesn't negate the point 
that the primary issue is that the startup conditions must be fully 
considered when designing in a micro, whether the resulting restrictions 
are the result of internal HW or internal SW is utterly irrelevant.  I 
suspect we have all missed a startup condition at one point or 
another.  I'm certain we've all found user documentation to be misleading 
at some point.

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

Um how do you lock out the HW in software?  You always have serial ISP 
available.

On the other hand From Luminary Micros Documentation

"Caution – If the JTAG pins will be used as GPIOs, it is possible to create 
a software sequence that
prevents the debugger from connecting to the Stellaris microcontroller. If 
the program code loaded
into flash immediately changes the JTAG pins to their GPIO functionality, 
the debugger will not
have enough time to connect and halt the controller before the JTAG pin 
functionality switches.
This locks the debugger out of the part. This can be avoided with a 
software routine that restores
JTAG functionality using an external trigger."

Since this appears to be how the micro is programmed it is quite possible 
to lock out the chip in SW.  So that suggests there is at least one micro 
that is possible to lock out the HW with SW.

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

What errata is that?  And how do you fix an failure to condition an analog 
input by changing the bootloader?

Besides which, surely conditioning an analog input is just basic 
design?  Is there something special needed?

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

I still run into that on occasion.  Web access makes proliferation easier 
but only when the company involved decides to publish the errata to begin with.

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/