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?
>
> thanks,
> GMMessage
Re: ISP reliability, and parts failing in the field
2004-03-23 by philips_apps
Attachments
- No local attachments were found for this message.