Yahoo Groups archive

Lpc2000

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

Message

Re: Tom's questions for Jaya

2006-02-23 by Guillermo Prandi

Brendan, Jayasooriah already said that the problem didn't go away 
with Philips' new bootloader. It only went away with Jayasooriah's 
own bootloader.

Guille

--- In lpc2000@yahoogroups.com, "brendanmurphy37" 
<brendan.murphy@...> wrote:
>
> 
> 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
> >
>

Attachments

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.