Forums

Re: Tom's questions for Jaya

Started by Jayasooriah February 24, 2006
Tom, what you say does not appear to add up:

>Message: 12
>    Date: Fri, 24 Feb 2006 17:06:25 -0000
>    From: "lpc2100" <lpc2100@lpc2...>
>Subject: Re: Tom's questions for Jaya
>
> > It is not possible to erase the boot loader by reading it out.  All my
> > reverse engineering was done using the hex file.
>
>Reverse engineering can also mean verifying your findings.

All my reverse engineering was done using the hex file.  (I can point you 
to the URL if you like to know more...)

As I explained, my findings during in FTL testing are that IAP calls failed 
and did not return.  Anyone who knows about FTL would immediately recognise 
how good FTL is in flushing out flash memory reliability problems.

I was also reminded that Philips took set an entire section to explain 
ECC  alludes one to problems with flash reliability.

While the ECC section appears to be a spin doctoring (reporting a bug as a 
feature) of defects in the ECC implementation, the fact that ECC is 
required IMO is there are flash reliability problems.

I have never previously worked with flash memories for which I could not 
take advantage of their NOR or NAND properties.

Philips most recently has given a further indication of this by stating 
"the bootloader is unlikely to get erased or corrupted during IAP call even

if wrong frequency is used."

This begs the question: what does happen then?

>What if you
>erased the philips bootloader while developing your own.

My boot loader (in the context of the FTL problem I reported) is no more 
than an application run by the Philips boot loader and which sits in sector 
0.  It does not have any flashing capability whatsoever.

It does not speak well of the LPC if the boot sector can be destroyed in 
the process of developing an "application", albeit this application
serves 
to load Intel-Hex formatted files into RAM, not flash.

>Anyway I can rest easy and hope other IAP users
too. It is safe to
>make IAP calls.

I have no objections to you resting easy, but advising other uses IMO does 
not make sense.  What is your justification for refuting my evidence?

Jaya 

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

An Engineer's Guide to the LPC2100 Series

I think anyone reading the message below, and in particular the 
statement "....there are flash reliability problems", needs to ask 
themselves what hard evidence is being produced for the claim.

I just raise this as a question: I've no intention of getting sucked 
into yet another discussion on whether particular problems exist or 
not.

Brendan

--- In lpc2000@lpc2..., Jayasooriah <jayasooriah@...> wrote:
>
> Tom, what you say does not appear to add up:
> 
> >Message: 12
> >    Date: Fri, 24 Feb 2006 17:06:25 -0000
> >    From: "lpc2100" <lpc2100@...>
> >Subject: Re: Tom's questions for Jaya
> >
> > > It is not possible to erase the boot loader by reading it out.  
All my
> > > reverse engineering was done using the
hex file.
> >
> >Reverse engineering can also mean verifying your findings.
> 
> All my reverse engineering was done using the hex file.  (I can 
point you 
> to the URL if you like to know more...)
> 
> As I explained, my findings during in FTL testing are that IAP 
calls failed 
> and did not return.  Anyone who knows about FTL
would immediately 
recognise 
> how good FTL is in flushing out flash memory
reliability problems.
> 
> I was also reminded that Philips took set an entire section to 
explain 
> ECC  alludes one to problems with flash
reliability.
> 
> While the ECC section appears to be a spin doctoring (reporting a 
bug as a 
> feature) of defects in the ECC implementation, the
fact that ECC is 
> required IMO is there are flash reliability problems.
> 
> I have never previously worked with flash memories for which I 
could not 
> take advantage of their NOR or NAND properties.
> 
> Philips most recently has given a further indication of this by 
stating 
> "the bootloader is unlikely to get erased or
corrupted during IAP 
call even 
> if wrong frequency is used."
> 
> This begs the question: what does happen then?
> 
> >What if you
> >erased the philips bootloader while developing your own.
> 
> My boot loader (in the context of the FTL problem I reported) is no 
more 
> than an application run by the Philips boot loader
and which sits 
in sector 
> 0.  It does not have any flashing capability
whatsoever.
> 
> It does not speak well of the LPC if the boot sector can be 
destroyed in 
> the process of developing an
"application", albeit this application 
serves 
> to load Intel-Hex formatted files into RAM, not
flash.
> 
> >Anyway I can rest easy and hope other IAP users too. It is safe to
> >make IAP calls.
> 
> I have no objections to you resting easy, but advising other uses 
IMO does 
> not make sense.  What is your justification for
refuting my 
evidence?
> 
> Jaya 
> 
> Send instant messages to your online friends 
http://au.messenger.yahoo.com
>
	
--- In lpc2000@lpc2..., Jayasooriah <jayasooriah@...> wrote:
>
> Tom, what you say does not appear to add up:
> 
> As I explained, my findings during in FTL testing are that IAP calls
failed 
> and did not return.  Anyone who knows about FTL
would immediately
recognise 
> how good FTL is in flushing out flash memory
reliability problems.
> 
> I was also reminded that Philips took set an entire section to explain 
> ECC  alludes one to problems with flash reliability.
> 
> While the ECC section appears to be a spin doctoring (reporting a
bug as a 
> feature) of defects in the ECC implementation, the
fact that ECC is 
> required IMO is there are flash reliability problems.
> 
> I have never previously worked with flash memories for which I could
not 
> take advantage of their NOR or NAND properties.
> 

Flash ECC requirement varies from technology, process, type. Nand
flash  memories have 16 bytes allocated per 512 bytes for ECC data.
Presence of ECC does not indicate a problem as long as data is intact.
AFAIK only Philips has cmos 18 embedded flash technology. ECC might be
a requirement at this process geometry.

> Philips most recently has given a further
indication of this by stating 
> "the bootloader is unlikely to get erased or corrupted during IAP
call even 
> if wrong frequency is used."
> 
> This begs the question: what does happen then?

Again this type of language is used by companies to avoid making
absolute claims. Does not bother me at all. I don't expect programming
/erase to succeed with wrong frequency.

> >What if you
> >erased the philips bootloader while developing your own.
> 
> My boot loader (in the context of the FTL problem I reported) is no
more 
> than an application run by the Philips boot loader
and which sits in
sector 
> 0.  It does not have any flashing capability
whatsoever.
> 
> It does not speak well of the LPC if the boot sector can be
destroyed in 
> the process of developing an
"application", albeit this application
serves 
> to load Intel-Hex formatted files into RAM, not
flash.
> 

Didn't you say (in some other post) that you have a better flash
programming algorithm than Philips? While developing that algorithm it
is possible to erase the boot sector. My apologies if you did not make
that claim.

> 
> I have no objections to you resting easy, but advising other uses
IMO does 
> not make sense.  What is your justification for
refuting my evidence?

Lack of concrete evidence (code example/conditions demonstrating the
problem). Thousands of lpc users around the world are
using IAP/ISP without any failure. BTW ISP also uses IAP to program
the flash. I expect to see a lot more users reporting erased boot
sector. So far there are only two. One of them turned out to be a
false alarm.

Tom