Lpc2000

Jaya,

Your reply below is interesting, but only in a historic sense (unless 
I'm missing something). The problem you referred to in IAP has been 
acknowledged by Philips and a fix provided (updated boot loader for 
some parts). 

I'll repeat the question I asked: do you have any evidence to back up 
your claim that the "boot loader is broken"?

To give some background on why this is important (to me): I'm 
currently involved in a project that uses the LPC2134. Right now, 
towards the end of a fairly lengthy development program and 
manufacture of some pre-production prototypes, we have no reason to 
suspect there is a problem with the boot loader. This statement is 
based on our own experience of using the parts. In a few months time 
we will be in production at a rate of a couple of thousand units per 
month. Every single one of these will be programmed using the built-
in boot loader. If there's any evidence that we may encounter a 
problem, either in production or in the field, I'd really, really, 
like to know about it now. 

I'm sure our situation is not unique. I'm also very sure Philips 
would be very interested in the answer.

Hence my question: is there any evidence of a problem with the 
(current) boot loader, based on empirical data (not opinion or 
supposition), that ought to concern me and the others who are using 
these parts?

If the answer's "no", then that's great. If it's "yes", can you 
please supply details of the specific problem you have observed, and 
the circumstances in which it occurs, so that I (and others) can 
evaluate any risk that might be present.

Many thanks in advance for any assistance you can give on this.

Regards
Brendan

--- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@...> wrote:
>
> --- 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
>