Lpc2000

--- In lpc2000@yahoogroups.com, "lpc2100" <lpc2100@...> wrote:
 >
 > Jayasooriah, I hope you don't mind me asking for proof. Please backup
 > the following statement of yours with solid evidence i.e. code example

Most recently Philips said "the bootloader is unlikely to get erased or 
corrupted during IAP call even if wrong frequency is used."  This is is 
proof enough from the horse's mouth that the problem exists.

 > You claim "I discovered that calls to the on-chip boot loader using
 > IAP interface caused corruption of on-chip flash in unexpected ways.
 > On two instances, part became unusable after IAP calls failed."

I noticed the system crashed frequently while porting my Flash Translation 
Layer (FTL) package from another system.  Most of the time I could recover 
by simply resetting, but one time too many I had to have to get the LPC2105 
replaced.

It would not come up in ISP mode no matter what.  No, I was not using the 
watchdog at all and yes I power cycling did not help.

After the second or third time this happened (I cannot remember), I looked 
at the errata sheet and found this problem documented as IAP calls that do 
not return.

I upgraded my boot loader from 1.03 to 1.52 but the problem did not go 
away.  [I really cannot remember if it got worse or better because code was 
volatile during that time.]

I then put probes before and after IAP calls and established I would lose 
the system during IAP calls, most of the time during writes but sometimes 
during erase too.

I looked at the flash algorithm implementation in 1.03 and 1.52 versions of 
the boot loader and worked out what was happening.  So I modified it to do 
what I thought it should be doing and lo and behold, my FTL project was 
done and over with in no time after that.

The above is my grounds on which I make the claim.  I still have two boards 
with dead LPC on my desk if someone wants to do forensics to confirm that 
boot loader is indeed dead.  I will swap it for good boards anytime.

 > This group can benefit from your exemplary research if you could post
 > the code example and conditions which can render part unusable. I am
 > willing to loose some parts. I hope Philips can fix the problem if it
 > exists.

Sure it would be nice bugs could be demonstrated by code examples.  Timing 
problems unfortunately depend on far too many variables to be reproduced in 
a deterministic manner.

Having said this, we know for a fact that there was a timing problem that 
causes IAP calls to not return, and this was addressed by way of a boot 
loader update.  Why is it not reasonable to ask if that did really fix the 
problem, given the code does not seem to do what it appears it ought to be 
doing?

Jaya

Send instant messages to your online friends http://au.messenger.yahoo.com