Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Thread

ISP reliability, and parts failing in the field

ISP reliability, and parts failing in the field

2004-03-10 by golssa

Hello,

the early LPC900 series (viz. P89LPC932) had serious reliability 
issues in 
that the ISP software would get confused by a problem in the 
oscillator and reset circuit inside the chip (or due to programming 
errors), and that would kill the chip:

The reset problem would make the chip execute from random addresses, 
with a chance to hit the ISP firmware, and this firmware would then 
randomly clobber memory, rendering the chip useless and the board 
dead, sometimes even overwriting its own ISP/IAP code. This happened 
on almost all of the chips(!), and Philips introduced special 
versions of the chip with a modified ISP software (due to the random 
program counter possibility this new firmware likely does not fix the 
issue 100%), and with the ISP software completely removed ("one-time-
programming").

Does anyone know if this or similar problems exists on the LPC2100 
series of 
chips too? Has anyone had any large volume mass production and/or 
many hours of reliability testing experience with these chips?

What are the chances of an errand pointer making the Arm jump into 
its ISP firmware, and delete portions of its flash memory randomly? 
How does one delete the ISP firmware for production boards to avoid 
this issue, and to avoid someone else reading out the users' software?

thanks,
GM

Re: ISP reliability, and parts failing in the field

2004-03-23 by philips_apps

GM,

The chances of LPC2000 parts showing such behavior are extremely low.
LPC2000 and LPC900 are different devices and different manufacturing 
process is used. They do not share reset/oscillator circuit.

Corrupted pointer jump into non existent memory space will cause 
prefetch abort.

In LPC2000 flash erase / write is a two step process which requires 
prepare operation first. Random jump in to ISP erase or write 
function won't result in an erase or write provided that the sector 
was not prepared. Two random jumps are unlikely i.e. first one in to 
prepare function and the second one in to write / erase function.
Also all parameters passed to the IAP function call go through 
strict parameter verification.

Unintentional erase could happen when a corrupted pointer jumps in to 
user "suicide" function.

There is no need to delete the isp firmware, just don't implement 
the "suicide" function. Code protection feature is available in 64 
and 144 pin devices. Please refer to 
http://groups.yahoo.com/group/lpc2000/message/1320 for more info.
 
Best Regards
Philips_apps

--- In lpc2000@yahoogroups.com, "golssa" <golssa@y...> wrote:
> Hello,
> 
> the early LPC900 series (viz. P89LPC932) had serious reliability 
> issues in 
> that the ISP software would get confused by a problem in the 
> oscillator and reset circuit inside the chip (or due to programming 
> errors), and that would kill the chip:
> 
> The reset problem would make the chip execute from random 
addresses, 
> with a chance to hit the ISP firmware, and this firmware would then 
> randomly clobber memory, rendering the chip useless and the board 
> dead, sometimes even overwriting its own ISP/IAP code. This 
happened 
> on almost all of the chips(!), and Philips introduced special 
> versions of the chip with a modified ISP software (due to the 
random 
> program counter possibility this new firmware likely does not fix 
the 
> issue 100%), and with the ISP software completely removed ("one-
time-
> programming").
> 
> Does anyone know if this or similar problems exists on the LPC2100 
> series of 
> chips too? Has anyone had any large volume mass production and/or 
> many hours of reliability testing experience with these chips?
> 
> What are the chances of an errand pointer making the Arm jump into 
> its ISP firmware, and delete portions of its flash memory randomly? 
> How does one delete the ISP firmware for production boards to avoid 
> this issue, and to avoid someone else reading out the users' 
software?
Show quoted textHide quoted text
> 
> thanks,
> GM

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.