Lpc2000

Peter, I am happy to accept your taunt ...

--- In lpc2000@yahoogroups.com, Peter Jakacki <peterjak@...> wrote:
 > Please tell us if this is for real. Are they your own findings? Maybe
 > you are gleaning off a student perhaps?, and that is why you are not
 > able to give us any concrete evidence. ***Take this as a friendly taunt,
 > one that you should be able to refute in a microsecond if you are
 > genuine. We just want to know facts, not enter into a slinging match,
 > otherwise just end this thread here and now.

They are my own findings.  Not based on client's findings or that of students.

What "concrete" evidence do you need?  Feel free to phrase your questions.

Regards,

Jaya

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

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

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."

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.

Tom

--- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@...> wrote:
>
> Peter, I am happy to accept your taunt ...
> 
> --- In lpc2000@yahoogroups.com, Peter Jakacki <peterjak@> wrote:
>  > Please tell us if this is for real. Are they your own findings? Maybe
>  > you are gleaning off a student perhaps?, and that is why you are not
>  > able to give us any concrete evidence. ***Take this as a friendly
taunt,
>  > one that you should be able to refute in a microsecond if you are
>  > genuine. We just want to know facts, not enter into a slinging match,
>  > otherwise just end this thread here and now.
> 
> They are my own findings.  Not based on client's findings or that of
students.
> 
> What "concrete" evidence do you need?  Feel free to phrase your
questions.
> 
> Regards,
> 
> Jaya
> 
> Send instant messages to your online friends
http://au.messenger.yahoo.com
>

--- 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

How can I call function where address is in pointer? Something like this:


void test1(void){
   puts("blah");
}


void *exec;

void main(void) {
    exec = (void *)test1;
    __asm
    {
    	BL 		exec
    }

...

It's out of context. There will be more pointers and *exec can be constant:
const void *exec = (void *)test1;


Thanks!

Marko

After setting:
    exec = (void *)test1;
Just call via exec:
     exec();

On 2/23/06, Marko Pavlin <mp@...> wrote:
>
>  How can I call function where address is in pointer? Something like this:
>
>
> void test1(void){
>    puts("blah");
> }
>
>
> void *exec;
>
> void main(void) {
>     exec = (void *)test1;
>     __asm
>     {
>           BL             exec
>     }
>
> ...
>
> It's out of context. There will be more pointers and *exec can be
> constant:
> const void *exec = (void *)test1;
>
>
> Thanks!
>
> Marko
>
>
>  SPONSORED LINKS
>   Microcontrollers<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=mfaAujKZXA2Z_vxre9sGnQ>
> Microprocessor<http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=9jjd2D3GOLIESVQssLmLsA>  Intel
> microprocessors<http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=OMnZuqMZX95mgutt4B-tDw>   Pic
> microcontrollers<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=Malspbd0T4Rq3M4Q0nHrfw>
>  ------------------------------
> YAHOO! GROUPS LINKS
>
>
>    -  Visit your group "lpc2000 <http://groups.yahoo.com/group/lpc2000>"
>    on the web.
>
>    -  To unsubscribe from this group, send an email to:
>     lpc2000-unsubscribe@yahoogroups.com<lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
>    -  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>    Service <http://docs.yahoo.com/info/terms/>.
>
>
>  ------------------------------
>



--
Jim Parziale
nuncio.bitis@...
Malden, MA


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

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
>

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
> >
>

Hi,

Define a function pointer:
STATUS (*ptrghigh_fxn)(uint8 evt, void *parg1, void *parg2); /* Pointer to the trigger function */

Initi it:
ptrghigh_fxn = &TriggerFxn;

Call it:
ptrghigh_fxn(1,2,3);

----------------------------------------------------------
Function:
STATUS TriggerFxn(uint8 ucEvent, void *pArg1, void *pArg2) {
   /* do something */
}

Hope it helps,
marko

---- Marko Pavlin <mp@...> piše: 

> How can I call function where address is in pointer? Something like this:
> 
> 
> void test1(void){
>    puts("blah");
> }
> 
> 
> void *exec;
> 
> void main(void) {
>     exec = (void *)test1;
>     __asm
>     {
>     	BL 		exec
>     }
> 
> ...
> 
> It's out of context. There will be more pointers and *exec can be constant:
> const void *exec = (void *)test1;
> 
> 
> Thanks!
> 
> Marko
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
>

--- In lpc2000@yahoogroups.com, "Guillermo Prandi" 
<yahoo.messenger@...> wrote:
>
> 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
> 

Guille,

Jayasooriah provides a description of a problem with an application 
using IAP. With the details provided I'd find it difficult to establish 
if the problem is with the application, the IAP functions or some 
combination of the two.

I'm trying to find out if there's a problem with the boot loader, which 
as I've explained we use to program the devices.

If there's any confision, I'll try and make the question simpler: "is 
there a problem with the boot loader that could cause it to fail to 
function, and if so, under what circumstances?"

In case there's any confusion over what the boot loader is: my 
understanding is that it's the first piece of software to run on the 
device, the primary function of which is to start any valid application 
it finds in flash or to load the flash through the serial port. This is 
the thing I'm being told is "broken".

I hope this clarifies matters.

Brendan

> Initi it:
> ptrghigh_fxn = &TriggerFxn;

The address operator & can be omitted in that case.

Thus

  ptrghigh_fxn = TriggerFxn;

renders the same functionality.



	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

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

Yes you are missing the something an important fact.  Boot loader update 
did not stop my code from falling over.  Replacing the flash algorithm did.

 > I'll repeat the question I asked: do you have any evidence to back up
 > your claim that the "boot loader is broken"?

I said it boot loader is broken because I am able crash the boot loader at 
will on my LPC 2292 irrespective of whether or not CRP is enabled.

 > 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?

See above.

 > 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.

Yes.  See above.

What happens when the boot loader crashes is indeterminate.  No exception 
handling makes matters worse.  In most security contexts, this poses 
unacceptable risks.

My task (what I am paid to do) is to mitigate or eliminate threats to 
security.  Providing a replacement boot loader is how I chose to do this. I 
looked at other options and these were either too expensive or did not 
mitigate enough.

 > Many thanks in advance for any assistance you can give on this.

You must get your own security assessment done for your particular situation.

 > Regards
 > Brendan

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

I also am at the end of a rather long development project on the verge of 
production roll out. I have been testing the LPC2134  processor for quite 
some time now and have not seen any issues with the boot loader. If it 
does exist then either I've been very lucky or the condition exists only 
under specific conditions.

Mike

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

* Marko Pavlin <mp@...>:
> >  How can I call function where address is in
> >  pointer? Something like this:
> >
> > void test1(void){
> >    puts("blah");
> > }
> >
> >
> > void *exec;
> >
> > void main(void) {
> >     exec = (void *)test1;
> >     __asm
> >     {
> >           BL             exec
> >     }

You need to declare exec as a function pointer.
Then you can assign it the address of any function
with the same prototype and call it like any other
function:

void test1(void){
   puts("blah");
}

void (*exec)(void); // Declare as function pointer.

void main(void) {
    exec = test1;
    exec();
}

* Jim Parziale <nuncio.bitis@...>:
> After setting:
>     exec = (void *)test1;
> Just call via exec:
>      exec();
> 

exec must be declared as a function pointer,
otherwise the compiler won't know how to set up
the parameters and pick up the return value for
the function (even if there are none in this
case.)

-- 
JR

Jaya,

Many thanks for the prompt answers. A couple of follow-up points below.

--- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@...> wrote:
> I said it boot loader is broken because I am able crash the boot 
loader at 
> will on my LPC 2292 irrespective of whether or not CRP is enabled.
> 

When you say you can crash the boot loader at will, are you talking 
about the boot loader itself crashing (i.e. during the boot process 
and/or flash load through the serial port), or an application that 
calls the IAP functions crashing? We don't use IAP. We do however, use 
the boot loader (as I imagine everyone else does).

Also, you mention the LPC2292. Do you happen to know if the problem you 
observed is present on the LPC2134?

As a minor point: we're happy with the security of the device. When I 
used the term risk assesment, I meant the normal evaluation of product 
prior to release to determine how likely it is we'll get problems in 
production and/or returns from the field.

I really apreciate your input on this, as I'm sure others do too.

Regards
Brendan

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

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

Hi,

Its rather a programming style. I prefer to add the & operator, so I am 
sure what I am doing. Everyone has his own style. Apart from this you 
are right - same functionality.

marko

haare_in_der_dusche wrote:

>>Initi it:
>>ptrghigh_fxn = &TriggerFxn;
>>    
>>
>
>The address operator & can be omitted in that case.
>
>Thus
>
>  ptrghigh_fxn = TriggerFxn;
>
>renders the same functionality.
>
>
>
>	
>
>	
>		
>___________________________________________________________ 
>Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>



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

> 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.
<snip>

Only Taxes and Death are certain (Don't recall who said that). Ok you
can evade taxes. No one makes absolute claim these days to avoid
liability. I won't worry about that statement. Have you got anything else?
> 
> 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.] <snip>

I have a different experience. After upgrade failing parts programmed
flawlessly. I don't read this group regularly. Did anyone else report
flash problems after upgrade on the group?
> 
> 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.
> 

Is it possible that you erased the philips bootloader while reverse
engineering the bootloader. Can't you revive the dead boards since you
have the ability to reprogram the boot sector with your own
bootloader. Have you tried to reprogram the chip via JTAG using your
own flash programming algorithms? If you can't access those chips via
jtag then this would indicate dead parts. This means that something
else went wrong which caused dead parts.

> 
> 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?

No offence but without a solid example above explanation sounds like
putting 2 and 2 together unscientifically.

Hello lpc2100, I will answer you question assuming it is an open question:

--- In lpc2000@yahoogroups.com, "lpc2100" <lpc2100@...> wrote:
 > Is it possible that you erased the philips bootloader while reverse
 > engineering the bootloader.

It is not possible to erase the boot loader by reading it out.  All my 
reverse engineering was done using the hex file.

 > Can't you revive the dead boards since you
 > have the ability to reprogram the boot sector with your own
 > bootloader.

If the boot loader is dead my loader does not get run.

 > Have you tried to reprogram the chip via JTAG using your
 > own flash programming algorithms?

No.

 > If you can't access those chips via
 > jtag then this would indicate dead parts.

I do not know.  See above.

 > This means that something
 > else went wrong which caused dead parts.

I do not know.  See above.

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

> 
> 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. What if you
erased the philips bootloader while developing your own.

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

Tom

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

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@yahoogroups.com, 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
>

I find Brendan Murphy's comments very unprofessional.  I am not sure if he 
is are deliberately being slippery.  Here is why I question his modus operandi:

1/  This thread was created by Tom (on my accepting Peter's taunt') to put 
his questions for discussion.

Brendan butts in with his requests for confirmation or denial of his 
wording of what I say as if he needs this clarification formally.

2/  He sends me long unsolicited private emails, two which I discovered 
while cleaning up my junk mailbox.  I responded to the third and and told 
you in in one line what I think he should do with private email to me.

When I refer to this conduct as:

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

he responds:

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


Now he says:

 > 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.

3/  What is this "hard evidence" I am supposed to put on on this forum for 
Brendan?  My application that failed, my fix of Philips "proprietary" flash 
algorithm?  What is unscientific and unclear about what I found:

a)  Application failed.  Traced it to IAP calls relating to flash erases 
and writes.

b)  Looked at the implementation of flash write and erase algorithms in 
boot loader (that IAP uses) and found defects.

c)  Fixed these defects.  Application no longer failed as it did before I 
fixed the defect.

d)  Explained what the fix is, how it addressed the problem using the above 
findings other information -- the problem was reasonably well documented 
despite the fact that the algorithm is "proprietary".

 > 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.

Yeah sure. 

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

--- In lpc2000@yahoogroups.com, 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

--- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@...> wrote:
>
> I find Brendan Murphy's comments very unprofessional.  I am not sure 
if he 
> is are deliberately being slippery.  Here is why I question his 
modus operandi:
> 
> 1/  This thread was created by Tom (on my accepting Peter's taunt') 
to put 
> his questions for discussion.
> 
> Brendan butts in with his requests for confirmation or denial of his 
> wording of what I say as if he needs this clarification formally.
> [...and mouch more along this vein]

I've already said I wasn't going to be sucked into more discussions on 
this, much less into trading abusive comments.

I won't be making any further comments on this whole series of related 
threads.

As I said before, people should and will make up their own minds on 
the merits of any message posted.

Brendan