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
Re: LPC FLASH security (CRP) broken?
Started by ●December 21, 2005
Reply by ●December 22, 20052005-12-22
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/
>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/
Reply by ●December 22, 20052005-12-22
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@lpc2..., "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
>
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@lpc2..., "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
>
Reply by ●December 22, 20052005-12-22
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@lpc2..., 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/
>
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@lpc2..., 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/
>
Reply by ●December 22, 20052005-12-22
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@lpc2..., "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
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@lpc2..., "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
Reply by ●December 22, 20052005-12-22
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@lpc2..., "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
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@lpc2..., "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
Reply by ●December 22, 20052005-12-22
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@lpc2..., "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..."
----------------
>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@lpc2..., "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..."
----------------
Reply by ●December 22, 20052005-12-22
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@lpc2..., 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&w451+microprocessor&c=4&s&.sig=tsVC-J9hJ5qyXg0WPR0l6g>
> Microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=DvJVNqC_pqRTm8Xq01nxwg>
> Pic microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=TpkoX4KofDJ7c6LyBvUqVQ>
>
> 8051 microprocessor
> <http://groups.yahoo.com/gads?t=ms&k51+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=1Ipf1Fjfbd_HVIlekkDP-A >
>
> >. >
>
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@lpc2..., 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&w451+microprocessor&c=4&s&.sig=tsVC-J9hJ5qyXg0WPR0l6g>
> Microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=DvJVNqC_pqRTm8Xq01nxwg>
> Pic microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=TpkoX4KofDJ7c6LyBvUqVQ>
>
> 8051 microprocessor
> <http://groups.yahoo.com/gads?t=ms&k51+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=1Ipf1Fjfbd_HVIlekkDP-A >
>
> >. >
>
Reply by ●December 22, 20052005-12-22
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@lpc2..., 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@lpc2..., 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&w451+microprocessor&c=4&s&.sig=tsVC-
J9hJ5qyXg0WPR0l6g>
> > Microcontrollers
> > <http://groups.yahoo.com/gads?
t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+
microcontrollers&w451+microprocessor&c=4&s&.sig=DvJVNqC_pqRTm8X
q01nxwg>
> > Pic microcontrollers
> > <http://groups.yahoo.com/gads?
t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=
Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=TpkoX4KofDJ
7c6LyBvUqVQ>
> >
> > 8051 microprocessor
> > <http://groups.yahoo.com/gads?
t=ms&k51+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=P
ic+microcontrollers&w451+microprocessor&c=4&s&.sig=1Ipf1Fjfbd_H
VIlekkDP-A>
> >
> >
> >
> > -----------------------------
-------
> > >.
> >
> >
> > -----------------------------
-------
>
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@lpc2..., 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@lpc2..., 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&w451+microprocessor&c=4&s&.sig=tsVC-
J9hJ5qyXg0WPR0l6g>
> > Microcontrollers
> > <http://groups.yahoo.com/gads?
t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+
microcontrollers&w451+microprocessor&c=4&s&.sig=DvJVNqC_pqRTm8X
q01nxwg>
> > Pic microcontrollers
> > <http://groups.yahoo.com/gads?
t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=
Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=TpkoX4KofDJ
7c6LyBvUqVQ>
> >
> > 8051 microprocessor
> > <http://groups.yahoo.com/gads?
t=ms&k51+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=P
ic+microcontrollers&w451+microprocessor&c=4&s&.sig=1Ipf1Fjfbd_H
VIlekkDP-A>
> >
> >
> >
> > -----------------------------
-------
> > >.
> >
> >
> > -----------------------------
-------
>
Reply by ●December 22, 20052005-12-22
