Lpc2000

Was Philips misleading us about Code Read Protection?

The preliminary user manual for LPC2119/2129/2194/2292/2294 dated 2004
May 03 in the section on CRP states:

> When the code read protection is enabled the JTAG debug
> port, external memory boot and the following ISP commands
> are disabled:
>
> • Read Memory
> • Write to RAM
> • Go
> • Copy RAM to Flash
>
> The ISP commands mentioned above terminate with return
> code CODE_READ_PROTECTION_ENABLED.
>
> The ISP erase command only allows erasure of all user
> sectors when the code read protection is enabled.

Philips stated (by way of poster dated Sat Dec 17, 2005  11:52 AM)
that the purpose of CRP as:

> Code Read Protection (CRP) was implemented with intention
> to protect on-chip Flash content from preying eyes.

It appears that Philips made these claims while it knew that CRP can
be defeated by other methods, including parallel programming or
booting from external memory.

1/  LPC parts without external memory interface support parallel
programming.  This method can be used to read and write on-chip flash.

2/  On LPC parts with external memory, it is possible to force the
part to boot on external memory.  Code in external memory can read and
write on-chip flash.

If the above claims are not true, it would be a simple matter for
Philips to say so.  The fact that Philips has chosen to go quiet on
this issue seems to suggest the claims are indeed true.

If this is the case, then clearly Philips has intentionally misled us.

Comments anyone?

Jaya

At 01:39 AM 12/22/05 +0000, jayasooriah wrote:
>Was Philips misleading us about Code Read Protection?
>
>The preliminary user manual for LPC2119/2129/2194/2292/2294 dated 2004
>May 03 in the section on CRP states:
>
> > When the code read protection is enabled the JTAG debug
> > port, external memory boot and the following ISP commands
> > are disabled:
> >
> > • Read Memory
> > • Write to RAM
> > • Go
> > • Copy RAM to Flash
> >
> > The ISP commands mentioned above terminate with return
> > code CODE_READ_PROTECTION_ENABLED.
> >
> > The ISP erase command only allows erasure of all user
> > sectors when the code read protection is enabled.
>
>Philips stated (by way of poster dated Sat Dec 17, 2005  11:52 AM)
>that the purpose of CRP as:
>
> > Code Read Protection (CRP) was implemented with intention
> > to protect on-chip Flash content from preying eyes.
>
>It appears that Philips made these claims while it knew that CRP can
>be defeated by other methods, including parallel programming or
>booting from external memory.
>
>1/  LPC parts without external memory interface support parallel
>programming.  This method can be used to read and write on-chip flash.

I've seen the hints you provided on this but no real evidence yet.  Since 
this appears to directly contradict what is on Philips Website I remain to 
be convinced.  You need to be able to show that the parts can be parallel 
programmed and that method of programming bypasses the CRP 
features.  Certainly if parallel programming is possible it raises that as 
a possibility since presumably the boot loader would not be involved.

There is another possibility though and that is that you have been the 
victim of marketing manipulation of terms.  It is quite possible that the 
references you have seen to parallel programming are just indicators that 
the devices can be programmed off board with an appropriate programmer and 
that programmer uses either the serial or JTAG ports to do the programming.


>2/  On LPC parts with external memory, it is possible to force the
>part to boot on external memory.  Code in external memory can read and
>write on-chip flash.

Well they do claim that turning on CRP disables the ability to boot from 
external memory.  Do you have any evidence to the contrary?  This does have 
the advantage of being easily tested.  Have you tested it and if so what 
did you use for a test case?  If not, why not?  With a test case this would 
be easy to duplicate and verify.

>If the above claims are not true, it would be a simple matter for
>Philips to say so.  The fact that Philips has chosen to go quiet on
>this issue seems to suggest the claims are indeed true.

Hey give them a bit of a chance.  They do, I think, need to respond.  If 
this is coming out of the blue they may need some time to figure out 
exactly what it is they are responding to.  Also at this season the people 
most able to respond may well be on vacation.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

Jaya,

I am truely sorry but I do not understand your point. A parallel 
programmer will not be able to read or program a secured device. A 
microcontroller that executes an external program can not be secured 
because the external code can always be compromised. Booting from 
external is not possible once the device is secured and programmed 
to boot internally.

Did I miss something?  Oh yes, you, the user is always able 
to "undo" your security while running IAP but how would a "spy" be 
ever able to run IAP (In application programming). The devices you 
mentioned also leave the option to reenable JTAG in your program, 
again, chicken and egg, as the spy will not be able to alter your 
program how can he enable JTAG. 

Philips Apps 


--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@y...> 
wrote:
>
> Was Philips misleading us about Code Read Protection?
> 
> The preliminary user manual for LPC2119/2129/2194/2292/2294 dated 
2004
> May 03 in the section on CRP states:
> 
> > When the code read protection is enabled the JTAG debug
> > port, external memory boot and the following ISP commands
> > are disabled:
> >
> > • Read Memory
> > • Write to RAM
> > • Go
> > • Copy RAM to Flash
> >
> > The ISP commands mentioned above terminate with return
> > code CODE_READ_PROTECTION_ENABLED.
> >
> > The ISP erase command only allows erasure of all user
> > sectors when the code read protection is enabled.
> 
> Philips stated (by way of poster dated Sat Dec 17, 2005  11:52 AM)
> that the purpose of CRP as:
> 
> > Code Read Protection (CRP) was implemented with intention
> > to protect on-chip Flash content from preying eyes.
> 
> It appears that Philips made these claims while it knew that CRP 
can
> be defeated by other methods, including parallel programming or
> booting from external memory.
> 
> 1/  LPC parts without external memory interface support parallel
> programming.  This method can be used to read and write on-chip 
flash.
> 
> 2/  On LPC parts with external memory, it is possible to force the
> part to boot on external memory.  Code in external memory can read 
and
> write on-chip flash.
> 
> If the above claims are not true, it would be a simple matter for
> Philips to say so.  The fact that Philips has chosen to go quiet on
> this issue seems to suggest the claims are indeed true.
> 
> If this is the case, then clearly Philips has intentionally misled 
us.

> 
> Comments anyone?
> 
> Jaya
>

Robert,

fyi, parallel programming is possible but the only thing parallel is 
the databus, in the end the parallel programmer again uses the 
bootloader for programming. 

The other Robert

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
>
> At 01:39 AM 12/22/05 +0000, jayasooriah wrote:
> >Was Philips misleading us about Code Read Protection?
> >
> >The preliminary user manual for LPC2119/2129/2194/2292/2294 dated 
2004
> >May 03 in the section on CRP states:
> >
> > > When the code read protection is enabled the JTAG debug
> > > port, external memory boot and the following ISP commands
> > > are disabled:
> > >
> > > • Read Memory
> > > • Write to RAM
> > > • Go
> > > • Copy RAM to Flash
> > >
> > > The ISP commands mentioned above terminate with return
> > > code CODE_READ_PROTECTION_ENABLED.
> > >
> > > The ISP erase command only allows erasure of all user
> > > sectors when the code read protection is enabled.
> >
> >Philips stated (by way of poster dated Sat Dec 17, 2005  11:52 AM)
> >that the purpose of CRP as:
> >
> > > Code Read Protection (CRP) was implemented with intention
> > > to protect on-chip Flash content from preying eyes.
> >
> >It appears that Philips made these claims while it knew that CRP 
can
> >be defeated by other methods, including parallel programming or
> >booting from external memory.
> >
> >1/  LPC parts without external memory interface support parallel
> >programming.  This method can be used to read and write on-chip 
flash.
> 
> I've seen the hints you provided on this but no real evidence 
yet.  Since 
> this appears to directly contradict what is on Philips Website I 
remain to 
> be convinced.  You need to be able to show that the parts can be 
parallel 
> programmed and that method of programming bypasses the CRP 
> features.  Certainly if parallel programming is possible it raises 
that as 
> a possibility since presumably the boot loader would not be 
involved.
> 
> There is another possibility though and that is that you have been 
the 
> victim of marketing manipulation of terms.  It is quite possible 
that the 
> references you have seen to parallel programming are just 
indicators that 
> the devices can be programmed off board with an appropriate 
programmer and 
> that programmer uses either the serial or JTAG ports to do the 
programming.
> 
> 
> >2/  On LPC parts with external memory, it is possible to force the
> >part to boot on external memory.  Code in external memory can 
read and
> >write on-chip flash.
> 
> Well they do claim that turning on CRP disables the ability to 
boot from 
> external memory.  Do you have any evidence to the contrary?  This 
does have 
> the advantage of being easily tested.  Have you tested it and if 
so what 
> did you use for a test case?  If not, why not?  With a test case 
this would 
> be easy to duplicate and verify.
> 
> >If the above claims are not true, it would be a simple matter for
> >Philips to say so.  The fact that Philips has chosen to go quiet 
on
> >this issue seems to suggest the claims are indeed true.
> 
> Hey give them a bit of a chance.  They do, I think, need to 
respond.  If 
> this is coming out of the blue they may need some time to figure 
out 
> exactly what it is they are responding to.  Also at this season 
the people 
> most able to respond may well be on vacation.
> 
> Robert
> 
> " 'Freedom' has no meaning of itself.  There are always 
restrictions,   be 
> they legal, genetic, or physical.  If you don't believe me, try to 
chew a 

> radio signal. "  -- Kelvin Throop, III
> http://www.aeolusdevelopment.com/
>

Pleae let me clarify.  I am seeking affirmative answers to the two
questions below so as to assure client that code in the LPC parts
(with CRP enabled) is secure.

According to the Product Overview Edition 08 2005 provide by Philips,
all of the LPC2100 series parts less 2194 is marked "Y" for Parallel
Programming (PP) feature column.

Client was told PP can read and program on-chip flash.  Philips (Jim
E) by email has advised me that I could use PP to re-load the on-chip
flash for LPC2105 parts that my students manage to kill just by bad
coding.

Client wants Philips to confirm that if the device is secured using
CRP, then PP cannot be used to access the on-chip flash.

Your say:
> A parallel programmer will not be able to read
> or program a secured device.

Q1: Can I tell client Philips has confirmed CRP is not voided by PP?

I am curious, what happens to a part when is CRP enabled, and if there
is no way to recover the part at all.

In the same Product Overview document referred to above, all of the
LPC2200 series parts that have external memory interface have a "-"
against the PP feature column.  If it was a "N", I would tell client
this means these devices do not support parallel programming.  I am
not sure what the "-" means.

If these devices cannot be parallel programming, how does the on-chip
flash gets loaded the first time, or after it has been corrupted?

Client was told that these parts are loaded (first time) by forcing
them to boot from external memory by pull downs on specific pins
during reset.

Q2: Would Philips confirm such methods cannot be used to defeat CRP?

I am curious how Philips loads the flash first time for these parts.

You make the statement:

> Oh yes, you, the user is always able to "undo" your
> security while running IAP but how would a "spy" be 
> ever able to run IAP (In application programming)

If the user can "undo" CRP, you must assume the "spy" can.

Security by obscurity (which attempts to use secrecy of design,
implementation, etc) to ensure security is not acceptable to the client.

As an example, Philips "secured" boot loader sector by keeping the
programing algorithms a secret.  My students killed two of my 2105
boards by accident.  I could not tell them what they should not do
because I did not know the programming algorithm.

I am sure there are many who have worked out the algorithm as I now
have.  How long do you think it takes for one of these persons to
publish the algorithm on the net, assuming this has yet to happen?

Jaya

--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...> wrote:

>
> Jaya,
> 
> I am truely sorry but I do not understand your point. A parallel 
> programmer will not be able to read or program a secured device. A 
> microcontroller that executes an external program can not be secured 
> because the external code can always be compromised. Booting from 
> external is not possible once the device is secured and programmed 
> to boot internally.
> 
> Did I miss something?  Oh yes, you, the user is always able 
> to "undo" your security while running IAP but how would a "spy" be 
> ever able to run IAP (In application programming). The devices you 
> mentioned also leave the option to reenable JTAG in your program, 
> again, chicken and egg, as the spy will not be able to alter your 
> program how can he enable JTAG. 
> 
> Philips Apps

Robert,

Now I am confused even more ... :(

According to your Jim E, I am able to reload the on-chip boot sector
using PP even when the boot loader has been corrupted or erased.

This must mean PP does not require or depend on the boot sector being
intact for programming purposes.  You are saying it does?

Jaya

--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...> wrote:

>
> Robert,
> 
> fyi, parallel programming is possible but the only thing parallel is 
> the databus, in the end the parallel programmer again uses the 
> bootloader for programming. 
> 
> The other Robert

jayasooriah wrote:

>Pleae let me clarify.  I am seeking affirmative answers to the two
>questions below so as to assure client that code in the LPC parts
>(with CRP enabled) is secure.
>
>According to the Product Overview Edition 08 2005 provide by Philips,
>all of the LPC2100 series parts less 2194 is marked "Y" for Parallel
>Programming (PP) feature column.
>
>Client was told PP can read and program on-chip flash.  Philips (Jim
>E) by email has advised me that I could use PP to re-load the on-chip
>flash for LPC2105 parts that my students manage to kill just by bad
>coding.
>
>Client wants Philips to confirm that if the device is secured using
>CRP, then PP cannot be used to access the on-chip flash.
>
>  
>

Good grief!  The last time I had a "secure" part with an external bus, I 
proved that I could defeat the "security" by enabling the external ROM 
and then reading the internal ROM.  There was a problem with that part.

Have you done nothing but 'read'?  Come on now, try it out, see if you 
can break it.  Spend some money, get a parallel programming setup, can 
you break it??

Sheesh

TomW


>Your say:
>  
>
>>A parallel programmer will not be able to read
>>or program a secured device.
>>    
>>
>
>Q1: Can I tell client Philips has confirmed CRP is not voided by PP?
>
>I am curious, what happens to a part when is CRP enabled, and if there
>is no way to recover the part at all.
>
>In the same Product Overview document referred to above, all of the
>LPC2200 series parts that have external memory interface have a "-"
>against the PP feature column.  If it was a "N", I would tell client
>this means these devices do not support parallel programming.  I am
>not sure what the "-" means.
>
>If these devices cannot be parallel programming, how does the on-chip
>flash gets loaded the first time, or after it has been corrupted?
>
>Client was told that these parts are loaded (first time) by forcing
>them to boot from external memory by pull downs on specific pins
>during reset.
>
>Q2: Would Philips confirm such methods cannot be used to defeat CRP?
>
>I am curious how Philips loads the flash first time for these parts.
>
>You make the statement:
>
>  
>
>>Oh yes, you, the user is always able to "undo" your
>>security while running IAP but how would a "spy" be 
>>ever able to run IAP (In application programming)
>>    
>>
>
>If the user can "undo" CRP, you must assume the "spy" can.
>
>Security by obscurity (which attempts to use secrecy of design,
>implementation, etc) to ensure security is not acceptable to the client.
>
>As an example, Philips "secured" boot loader sector by keeping the
>programing algorithms a secret.  My students killed two of my 2105
>boards by accident.  I could not tell them what they should not do
>because I did not know the programming algorithm.
>
>I am sure there are many who have worked out the algorithm as I now
>have.  How long do you think it takes for one of these persons to
>publish the algorithm on the net, assuming this has yet to happen?
>
>Jaya
>
>--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...> wrote:
>  
>
>>Jaya,
>>
>>I am truely sorry but I do not understand your point. A parallel 
>>programmer will not be able to read or program a secured device. A 
>>microcontroller that executes an external program can not be secured 
>>because the external code can always be compromised. Booting from 
>>external is not possible once the device is secured and programmed 
>>to boot internally.
>>
>>Did I miss something?  Oh yes, you, the user is always able 
>>to "undo" your security while running IAP but how would a "spy" be 
>>ever able to run IAP (In application programming). The devices you 
>>mentioned also leave the option to reenable JTAG in your program, 
>>again, chicken and egg, as the spy will not be able to alter your 
>>program how can he enable JTAG. 
>>
>>Philips Apps
>>    
>>
>
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

If the parallell programming is done by the bootloader, and the serial 
programming is done by the bootloader, and the JTAG is controlled by the 
bootloader, How the bootloader is programmed for the first time (in 
factory ) ????

Another question:
Is it possible to erase the bootloader using the provided IAP calls ? If 
so, is there anyway to recover it ?

Mauricio



> Robert,
>
> fyi, parallel programming is possible but the only thing parallel is
> the databus, in the end the parallel programmer again uses the
> bootloader for programming.
>
> The other Robert
>
> --- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...>
> wrote:
> >
> > At 01:39 AM 12/22/05 +0000, jayasooriah wrote:
> > >Was Philips misleading us about Code Read Protection?
> > >
> > >The preliminary user manual for LPC2119/2129/2194/2292/2294 dated
> 2004
> > >May 03 in the section on CRP states:
> > >
> > > > When the code read protection is enabled the JTAG debug
> > > > port, external memory boot and the following ISP commands
> > > > are disabled:
> > > >
> > > > . Read Memory
> > > > . Write to RAM
> > > > . Go
> > > > . Copy RAM to Flash
> > > >
> > > > The ISP commands mentioned above terminate with return
> > > > code CODE_READ_PROTECTION_ENABLED.
> > > >
> > > > The ISP erase command only allows erasure of all user
> > > > sectors when the code read protection is enabled.
> > >
> > >Philips stated (by way of poster dated Sat Dec 17, 2005  11:52 AM)
> > >that the purpose of CRP as:
> > >
> > > > Code Read Protection (CRP) was implemented with intention
> > > > to protect on-chip Flash content from preying eyes.
> > >
> > >It appears that Philips made these claims while it knew that CRP
> can
> > >be defeated by other methods, including parallel programming or
> > >booting from external memory.
> > >
> > >1/  LPC parts without external memory interface support parallel
> > >programming.  This method can be used to read and write on-chip
> flash.
> >
> > I've seen the hints you provided on this but no real evidence
> yet.  Since
> > this appears to directly contradict what is on Philips Website I
> remain to
> > be convinced.  You need to be able to show that the parts can be
> parallel
> > programmed and that method of programming bypasses the CRP
> > features.  Certainly if parallel programming is possible it raises
> that as
> > a possibility since presumably the boot loader would not be
> involved.
> >
> > There is another possibility though and that is that you have been
> the
> > victim of marketing manipulation of terms.  It is quite possible
> that the
> > references you have seen to parallel programming are just
> indicators that
> > the devices can be programmed off board with an appropriate
> programmer and
> > that programmer uses either the serial or JTAG ports to do the
> programming.
> >
> >
> > >2/  On LPC parts with external memory, it is possible to force the
> > >part to boot on external memory.  Code in external memory can
> read and
> > >write on-chip flash.
> >
> > Well they do claim that turning on CRP disables the ability to
> boot from
> > external memory.  Do you have any evidence to the contrary?  This
> does have
> > the advantage of being easily tested.  Have you tested it and if
> so what
> > did you use for a test case?  If not, why not?  With a test case
> this would
> > be easy to duplicate and verify.
> >
> > >If the above claims are not true, it would be a simple matter for
> > >Philips to say so.  The fact that Philips has chosen to go quiet
> on
> > >this issue seems to suggest the claims are indeed true.
> >
> > Hey give them a bit of a chance.  They do, I think, need to
> respond.  If
> > this is coming out of the blue they may need some time to figure
> out
> > exactly what it is they are responding to.  Also at this season
> the people
> > most able to respond may well be on vacation.
> >
> > Robert
> >
> > " 'Freedom' has no meaning of itself.  There are always
> restrictions,   be
> > they legal, genetic, or physical.  If you don't believe me, try to
> chew a
> > radio signal. "  -- Kelvin Throop, III
> > http://www.aeolusdevelopment.com/
> >
>
>
>
>
>
>
> SPONSORED LINKS
> Microprocessor 
> <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=tsVC-J9hJ5qyXg0WPR0l6g> 
> 	Microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=DvJVNqC_pqRTm8Xq01nxwg> 
> 	Pic microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=TpkoX4KofDJ7c6LyBvUqVQ> 
>
> 8051 microprocessor 
> <http://groups.yahoo.com/gads?t=ms&k=8051+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=1Ipf1Fjfbd_HVIlekkDP-A> 
>
>
>
> ------------------------------------------------------------------------
> 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
>       <mailto: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/>.
>
>
> ------------------------------------------------------------------------
>



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

Mauricio,

with IAP calls you can not erase the bootloader, it protects itself 
as it knows where it is located.

I can assure you we have an options to program the virgin device on 
a tester.

Regards, Robert

--- In lpc2000@yahoogroups.com, Mauricio Scaff <scaffm@g...> wrote:
>
> If the parallell programming is done by the bootloader, and the 
serial 
> programming is done by the bootloader, and the JTAG is controlled 
by the 
> bootloader, How the bootloader is programmed for the first time 
(in 
> factory ) ????
> 
> Another question:
> Is it possible to erase the bootloader using the provided IAP 
calls ? If 
> so, is there anyway to recover it ?
> 
> Mauricio
> 
> 
> 
> > Robert,
> >
> > fyi, parallel programming is possible but the only thing 
parallel is
> > the databus, in the end the parallel programmer again uses the
> > bootloader for programming.
> >
> > The other Robert
> >
> > --- In lpc2000@yahoogroups.com, Robert Adsett 
<subscriptions@a...>
> > wrote:
> > >
> > > At 01:39 AM 12/22/05 +0000, jayasooriah wrote:
> > > >Was Philips misleading us about Code Read Protection?
> > > >
> > > >The preliminary user manual for LPC2119/2129/2194/2292/2294 
dated
> > 2004
> > > >May 03 in the section on CRP states:
> > > >
> > > > > When the code read protection is enabled the JTAG debug
> > > > > port, external memory boot and the following ISP commands
> > > > > are disabled:
> > > > >
> > > > > . Read Memory
> > > > > . Write to RAM
> > > > > . Go
> > > > > . Copy RAM to Flash
> > > > >
> > > > > The ISP commands mentioned above terminate with return
> > > > > code CODE_READ_PROTECTION_ENABLED.
> > > > >
> > > > > The ISP erase command only allows erasure of all user
> > > > > sectors when the code read protection is enabled.
> > > >
> > > >Philips stated (by way of poster dated Sat Dec 17, 2005  
11:52 AM)
> > > >that the purpose of CRP as:
> > > >
> > > > > Code Read Protection (CRP) was implemented with intention
> > > > > to protect on-chip Flash content from preying eyes.
> > > >
> > > >It appears that Philips made these claims while it knew that 
CRP
> > can
> > > >be defeated by other methods, including parallel programming 
or
> > > >booting from external memory.
> > > >
> > > >1/  LPC parts without external memory interface support 
parallel
> > > >programming.  This method can be used to read and write on-
chip
> > flash.
> > >
> > > I've seen the hints you provided on this but no real evidence
> > yet.  Since
> > > this appears to directly contradict what is on Philips Website 
I
> > remain to
> > > be convinced.  You need to be able to show that the parts can 
be
> > parallel
> > > programmed and that method of programming bypasses the CRP
> > > features.  Certainly if parallel programming is possible it 
raises
> > that as
> > > a possibility since presumably the boot loader would not be
> > involved.
> > >
> > > There is another possibility though and that is that you have 
been
> > the
> > > victim of marketing manipulation of terms.  It is quite 
possible
> > that the
> > > references you have seen to parallel programming are just
> > indicators that
> > > the devices can be programmed off board with an appropriate
> > programmer and
> > > that programmer uses either the serial or JTAG ports to do the
> > programming.
> > >
> > >
> > > >2/  On LPC parts with external memory, it is possible to 
force the
> > > >part to boot on external memory.  Code in external memory can
> > read and
> > > >write on-chip flash.
> > >
> > > Well they do claim that turning on CRP disables the ability to
> > boot from
> > > external memory.  Do you have any evidence to the contrary?  
This
> > does have
> > > the advantage of being easily tested.  Have you tested it and 
if
> > so what
> > > did you use for a test case?  If not, why not?  With a test 
case
> > this would
> > > be easy to duplicate and verify.
> > >
> > > >If the above claims are not true, it would be a simple matter 
for
> > > >Philips to say so.  The fact that Philips has chosen to go 
quiet
> > on
> > > >this issue seems to suggest the claims are indeed true.
> > >
> > > Hey give them a bit of a chance.  They do, I think, need to
> > respond.  If
> > > this is coming out of the blue they may need some time to 
figure
> > out
> > > exactly what it is they are responding to.  Also at this season
> > the people
> > > most able to respond may well be on vacation.
> > >
> > > Robert
> > >
> > > " 'Freedom' has no meaning of itself.  There are always
> > restrictions,   be
> > > they legal, genetic, or physical.  If you don't believe me, 
try to
> > chew a
> > > radio signal. "  -- Kelvin Throop, III
> > > http://www.aeolusdevelopment.com/
> > >
> >
> >
> >
> >
> >
> >
> > SPONSORED LINKS
> > Microprocessor 
> > <http://groups.yahoo.com/gads?
t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+mi
crocontrollers&w4=8051+microprocessor&c=4&s=93&.sig=tsVC-
J9hJ5qyXg0WPR0l6g> 
> > 	Microcontrollers 
> > <http://groups.yahoo.com/gads?
t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+
microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=DvJVNqC_pqRTm8X
q01nxwg> 
> > 	Pic microcontrollers 
> > <http://groups.yahoo.com/gads?
t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=
Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=TpkoX4KofDJ
7c6LyBvUqVQ> 
> >
> > 8051 microprocessor 
> > <http://groups.yahoo.com/gads?
t=ms&k=8051+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=P
ic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=1Ipf1Fjfbd_H
VIlekkDP-A> 
> >
> >
> >
> > -----------------------------------------------------------------
-------
> > 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
> >       <mailto: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/>.
> >
> >
> > -----------------------------------------------------------------
-------

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

I am not Elvis, but "I Gotta Know".

Is here anyone dealing with wireless 802.15.4 on LPC21xx  or even using 
Chipcon CC2420 with LPC21xx, or "I'll be one and only till the end of time"?

Thank you!
Marko

philips_apps wrote:
> Mauricio,
>
> with IAP calls you can not erase the bootloader, it protects itself
> as it knows where it is located.
>
Ok. It sounds good.


> I can assure you we have an options to program the virgin device on
> a tester.
>
Let's say that your answer is a little bit obscure. So my code is 
protected as far as no one knows what happens in that "tester" ? It 
doesn't look like something very safe.

Client : - Is my code secure in this device ?
Me  : - Yes, of course. Noboby can read your code. Well, Philips can, 
but they told me that they will never tell how to do that.... By the 
way, may you give me your bank account and password please ?

> Regards, Robert
>
>

Mauricio


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

> with IAP calls you can not erase the bootloader, it protects itself
> as it knows where it is located.

How is a bootloader 'update' handled if IAP calls cannot erase the
bootloader?

> I can assure you we have an options to program the virgin device on
> a tester.

Can any of these 'options' read a device?
 
Is CRP solely implemented in the software based bootloader?



Joel

> Message: 10        
>    Date: Thu, 22 Dec 2005 20:58:17 +0100
>    From: "Marko Pavlin (home)" <mp@...>
> Subject: I Gotta Know
> 
> I am not Elvis, but "I Gotta Know".
> 
> Is here anyone dealing with wireless 802.15.4 on LPC21xx  or 
> even using 
> Chipcon CC2420 with LPC21xx, or "I'll be one and only till 
> the end of time"?
> 
> Thank you!
> Marko

Marko,

I've been using the CC2420 for quite awhile on the AVR's, actually, the
availability of GCC on the LPC and the existence of some template libs for
the CC2420 was the primary reason I started investigating the LPC's.

Steve

--- In lpc2000@yahoogroups.com, Mauricio Scaff <scaffm@g...> wrote:
> 
> 
> > I can assure you we have an options to program the virgin device on
> > a tester.
> >
> Let's say that your answer is a little bit obscure. So my code is 
> protected as far as no one knows what happens in that "tester" ? It 
> doesn't look like something very safe.
> 

How can you catagorize it as not "very safe" without even knowing what
a "tester" is??  A tester, like the HP3000, is often used to test
devices while they are still on the wafer prior to packaging.  Devices
at that stage are far more accesible than they are after they are
packaged, and all you can get at are the pins or balls. It could also
program the device via access methods that become completely
unavailable after packaging. For instance, if the device is a "stacked
die" part, then it could be programed before the dice are even bonded
out. This is not to say that is what is actually happening, but just
to point out that making a judgement from a position of no knowledge
is not likely to be very profitable to anyone.

BTW, if you are assuming that what is happening is just hidden access
mechanisms on completed parts, then I would agree that you are
justified in worrying about security. "Security by obscurity" always
fails eventually.

-- Dave

The bootloader is updated by a program that is uploaded to the internal 
ram. I guess this program contains the flash programming code itself and 
it does not use the iap calls at any time.

Richard.


Joel Winarske wrote:

> > with IAP calls you can not erase the bootloader, it protects itself
> > as it knows where it is located.
>
> How is a bootloader 'update' handled if IAP calls cannot erase the
> bootloader?
>
> > I can assure you we have an options to program the virgin device on
> > a tester.
>
> Can any of these 'options' read a device?
>
> Is CRP solely implemented in the software based bootloader?
>
>
>
> Joel
>
>
>
>
> SPONSORED LINKS
> Microprocessor 
> <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=tsVC-J9hJ5qyXg0WPR0l6g> 
> 	Microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=DvJVNqC_pqRTm8Xq01nxwg> 
> 	Pic microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=TpkoX4KofDJ7c6LyBvUqVQ> 
>
> 8051 microprocessor 
> <http://groups.yahoo.com/gads?t=ms&k=8051+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=1Ipf1Fjfbd_HVIlekkDP-A> 
>
>
>
> ------------------------------------------------------------------------
> 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
>       <mailto: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/>.
>
>
> ------------------------------------------------------------------------
>

At 05:05 AM 12/22/05 +0000, philips_apps wrote:
>Robert,
>
>fyi, parallel programming is possible but the only thing parallel is
>the databus, in the end the parallel programmer again uses the
>bootloader for programming.

Thanks Robert, Any chance of this being documented for us mere mortals 
:)  or is it reserved for device programmer manufacturers.

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

Dear Robert,

Could you also confirm you have no options to read a CRP enabled
device on your tester?

The gripe here is that client requirements are quite clear.  The
client will not use a part unless the manufactur guarantees there are
no (known) hidden or undisclosed methods tha the manufacture has
chosen not to disclose that the "enemy" can use to read locked down code.

The client did not say this explicitly, but it my guess that this
client thinks that if Philips chose not to disclose LPC flash
programming algorithm, it may well likewise chose not to disclose
methods or open holes in in the implementation that defeat CRP.

I know the client is happy with protection oferred in AVR device, and
is looking to LPC for other requirements, but the trust component is
not there yet in relation to Philips.

For this reason, I would suggest Philips put effort on this front in
relation to CRP feature if it wants LPC parts to be used in the same
league as AVR parts.

Regards,

Jaya

--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...> wrote:

>
> Mauricio,
> 
> with IAP calls you can not erase the bootloader, it protects itself 
> as it knows where it is located.
> 
> I can assure you we have an options to program the virgin device on 
> a tester.
> 
> Regards, Robert

Robert,

The other Robert (from Philips) appears to be talking about something
else.

The PP method I was referring is quite well documented for 87C576
(which is also ticked as "Y" for PP field in the Product Selection
Guide that started this thread) in Application Note 455.

http://www.semiconductors.philips.com/acrobat_download/applicationnotes/AN455.pdf

Jaya

>
> At 05:05 AM 12/22/05 +0000, philips_apps wrote:
> >Robert,
> >
> >fyi, parallel programming is possible but the only thing parallel is
> >the databus, in the end the parallel programmer again uses the
> >bootloader for programming.
> 
> Thanks Robert, Any chance of this being documented for us mere mortals 
> :)  or is it reserved for device programmer manufacturers.
> 
> " 'Freedom' has no meaning of itself.  There are always
restrictions,   be 
> they legal, genetic, or physical.  If you don't believe me, try to
chew a 

> radio signal. "  -- Kelvin Throop, III
> http://www.aeolusdevelopment.com/
>