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
Re: Tom's questions for Jaya
Started by ●February 24, 2006
Reply by ●February 27, 20062006-02-27
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 >
Reply by ●February 27, 20062006-02-27
--- 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
