Lpc2000

I'm hoping someone can shed some light on the following intermittent
LPC2129 power-up problem:

Power is applied; V18, V3, V18A and V3A become stable within 600us, the
clock stabilises 1ms later. After a further 250ms nRESET is taken high,
but the code doesn't appear to run.

Once in this state I can stop execution using a JTAG debugger and
examine the PC & other register contents. Sometimes the device appears
to be in a Prefetch Abort exception with the program counter continually
running from 0x0000000C, (prefetch abort handler address), through
0x0003FFFF, (top of Flash). On other occasions the device appears to be
executing a "loop forever" branch to itself that sits just after
the call to my C code in the startup assembly code. This loop would
normally be entered only if the C code exits, (which it shouldn't).

Please can anyone tell me if both of these conditions are consistent
with the Reset.1 errata from the latest published errata sheet
<http://www.semiconductors.philips.com/acrobat/erratasheets/2129.pdf> ? 
If so, why are some devices very prone to this problem, (approx 1 time
in 30), while others cannot be provoked no matter how long one spends
power-cycling the board?

If I can understand the external conditions, (if any), that provoke this
problem then I may be able to reduce the likelihood of it occurring.

Regards,

Dave Ashton




[Non-text portions of this message have been removed]

Thanks to Robert Teufel for providing me with the following information.
I wish the support from other chip manufacturers could be this good.

The problem is tied to a very small time window within each clock
period. If a transition of the reset comes exactly during this time some
Flash configuration bytes do not get transferred. As a result, reading
the Flash though possible, uses a wrong configuration and usually it
reads all FF, however it could also read partially correct values as the
values transferred into the flash configuration bytes are undefined.



You can reduce the likelihood by using the slowest external clock
possible (less clocks during reset and so less time windows for the
issue to occur). So if you use 16 MHz today, try 12 MHz or even 10 MHz
if it fits your needs.  The only reliable work around is to apply a
second reset after the specified time in the Errata Sheet.

In approx. 6 weeks we should be able to provide sufficient quantities of
the LPC2129/00 which still has all the Erratas except the startup
problems.

Best regards, Robert Teufel
Software Development Manager




[Non-text portions of this message have been removed]

--- In lpc2000@yahoogroups.com, "Dave Ashton" <g6gev@...> wrote:
> <quotes Robert Teufel as having said>
> In approx. 6 weeks we should be able to provide sufficient
> quantities of the LPC2129/00 which still has all the Erratas
> except the startup problems.
> 
> Best regards, Robert Teufel
> Software Development Manager

I had to deal with a similar (same?) RESET.1 problem for LPC2292 for
which the errata says:

> The root cause for this problem has been identified and
> will be fixed from Revision B of this device onwards.

Client who is anxiously waiting for Revision B to turn up in June (as
promised) before making a decision is assuming that other defects
relating to CAN, CORE, UART and TIMER bugs will also be addressed in
Revisin B.

But the comment from Philips seems to confirm that only RESET.1 bug
will be fixed in Revision B.

Does this mean Philips is not addressing any (all) other bugs in the
errata sheets at all?  Anyone has better information?

Jaya