Lpc2000

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
>