Lpc2000

Hi Mike,

While looking at the boot loader implementation, I noticed a segment of 
code in the Command String Interpreter (CSI) did not look right.  I 
confirmed it was a bug by crafting an input line and observing boot loader 
crash in response.

This sequence of input is not what one would normally enter when one uses 
the ISP to do things in accordance with the user manual.  It perhaps can 
occur when the interacting program (for example during field updates) 
misbehaves.

Such a bug in the CSI poses unacceptable risks when CRP is contemplated.

Where CRP is not needed, you have to consider what happens after the boot 
loader crashes.  These would include:

* Is it always possible to recover?
* Does external reset work?
* Do you need power cycling?
* What happens no recovery is attempted for a length of time?
* Are there any temporal changes?  Can this result in your application 
failing because it relied on the integrity of "reset" state?
* Are there any persistent changes, for example to the contents of on-chip 
flash?

There is no general answer to the above questions because when something 
like this happen, we say what happens is "indeterminate".  We cannot 
determine what happens because too many other factors that we cannot 
control or account for come in to play, including what application code it 
is running and what is the current state of on-chip RAM.

Normally, I do not advocate undertaking such an investigation because it is 
likely to be expensive yet inconclusive.  Fixing the boot loader is the the 
preferred option.  As I do not have access to the source I wrote my own.

Hope this helps.

Jaya

>Message: 7
>    Date: Thu, 23 Feb 2006 10:02:05 -0500
>    From: mfrazier@...
>Subject: Re: Re: Tom's questions for Jaya
>
>You say at will...what exactly are you doing that causes this failure?? We
>also have a project in mid stages of development that use the LPC2292 and
>speaking with other engineers on the project they claim they have not yet
>had any issues.
>
>Thanks,
>Mike

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

OK - so finally we have an answer. 

It would help if you could share what this "sequence of input is": 
it would (a) give people an opportuinity to see how likely it is to 
occur in practice and (b) give Philips the opportunity to to fix the 
problem.

It would also have been a lot more useful and less time consuming 
all around, if you could have mentioned this in the first place.

In conclusion, though, is it correct to say that provided you 
interact with the bootloader according to the documented interfaces 
there is no evidence that anything unexpected has been observed?

Brendan

--- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@...> wrote:
>
> Hi Mike,
> 
> While looking at the boot loader implementation, I noticed a 
segment of 
> code in the Command String Interpreter (CSI) did not look right.  
I 
> confirmed it was a bug by crafting an input line and observing 
boot loader 
> crash in response.
> 
> This sequence of input is not what one would normally enter when 
one uses 
> the ISP to do things in accordance with the user manual.  It 
perhaps can 
> occur when the interacting program (for example during field 
updates) 
> misbehaves.
> 
> Such a bug in the CSI poses unacceptable risks when CRP is 
contemplated.
> 
> Where CRP is not needed, you have to consider what happens after 
the boot 
> loader crashes.  These would include:
> 
> * Is it always possible to recover?
> * Does external reset work?
> * Do you need power cycling?
> * What happens no recovery is attempted for a length of time?
> * Are there any temporal changes?  Can this result in your 
application 
> failing because it relied on the integrity of "reset" state?
> * Are there any persistent changes, for example to the contents of 
on-chip 
> flash?
> 
> There is no general answer to the above questions because when 
something 
> like this happen, we say what happens is "indeterminate".  We 
cannot 
> determine what happens because too many other factors that we 
cannot 
> control or account for come in to play, including what application 
code it 
> is running and what is the current state of on-chip RAM.
> 
> Normally, I do not advocate undertaking such an investigation 
because it is 
> likely to be expensive yet inconclusive.  Fixing the boot loader 
is the the 
> preferred option.  As I do not have access to the source I wrote 
my own.
> 
> Hope this helps.
> 
> Jaya
> 
> >Message: 7
> >    Date: Thu, 23 Feb 2006 10:02:05 -0500
> >    From: mfrazier@...
> >Subject: Re: Re: Tom's questions for Jaya
> >
> >You say at will...what exactly are you doing that causes this 
failure?? We
> >also have a project in mid stages of development that use the 
LPC2292 and
> >speaking with other engineers on the project they claim they have 
not yet
> >had any issues.
> >
> >Thanks,
> >Mike
> 
> Send instant messages to your online friends 
http://au.messenger.yahoo.com
>

--- In lpc2000@yahoogroups.com, "brendanmurphy37" <brendan.murphy@...> wrote:
 > OK - so finally we have an answer.

I am glad you finally understood what CSI bug is after I reported another 
such bug months ago.

 > It would also have been a lot more useful and less time consuming
 > all around, if you could have mentioned this in the first place.

You would have realised I did this if only you spent less time attacking 
the messenger and put more effort in digesting the message.

 > In conclusion, though, is it correct to say that provided you
 > interact with the bootloader according to the documented interfaces
 > there is no evidence that anything unexpected has been observed?

I do not wish to start another flame war.  It is best you consult your a 
lawyer if you need a particular wording or interpretation confirmed or denied.

I have put on this forum as much as I am prepared to.  Time to move on.

Jaya

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

--- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@...> wrote:
>
> I am glad you finally understood what CSI bug is after I reported 
another 
> such bug months ago.

Jaya, like a lot of people, I don't have the time to monitor the 
forum continuously: only when there's some live topic that's of 
interest or relevance to me. Maybe it would help if when you make a 
claim (that, if true, would have a significant negative impact on 
others) you can supply the evidence with the claim? If your claim 
relied on behaviour you'd previously reported, why not just refer 
people to it? It's taken the best part of a week to establish the 
basis for your statement "the bootloader is broken".  Once people 
have the evidence, they can make up their own mind. In my case, based 
on what I've heard, I'm happy to proceed with using the boot loader 
as it is. If you or others disagree with this, that's fine. I've no 
interest in debating the issue, just in establishing the basis for 
the original claim.

> You would have realised I did this if only you spent less time 
attacking 
> the messenger and put more effort in digesting the message.

I'd hardly call asking for evidence for a claim as attacking the 
messenger!

> I do not wish to start another flame war.  It is best you consult 
your a 
> lawyer if you need a particular wording or interpretation confirmed 
or denied.

No need for lawyers: the only reason I felt the need to keep re-
phrasing the question because it wasn't being answered: I'd assumed 
there was some misunderstanding, or I wasn't making myself clear.

> 
> I have put on this forum as much as I am prepared to.  Time to move 
on.

I couldn't agree more!

Brendan

Thanks!...I appreciate you taking the time to explain the situation.

Thanks again,
Mike

[Non-text portions of this message have been removed]