EmbeddedRelated.com
Forums
Memfault Beyond the Launch

Lpc210x Code Protection

Started by mauroansa March 29, 2007
Hello.
I'm looking for a suitable way to protect the code on my lpc2103.
The device is programmed using the jLink jtag interface. I Have read
about the CRP protection, but confused about the use of it and the
effectiveness against ROM boot loader and jTag interface.
Can somebody hive me hints or link where to look at?

Thanks in advance for help.
Mauro Ansaloni

An Engineer's Guide to the LPC2100 Series

--- In l..., "mauroansa" wrote:
>
> Hello.
> I'm looking for a suitable way to protect the code on my lpc2103.
> The device is programmed using the jLink jtag interface. I Have
read
> about the CRP protection, but confused about the use of it and the
> effectiveness against ROM boot loader and jTag interface.
> Can somebody hive me hints or link where to look at?
>
> Thanks in advance for help.
> Mauro Ansaloni
>

CRP is easy enough to use: it's documented in the User Manual of the
relevant parts.

As for effectiveness, there's no evidence that there's any problem
with it, other than (possibly) for LPC2292 parts with bootloader
version 1.64.

True enough, you need a pretty powerful noise filter to reach that
conclusion, but I believe it to be acurate.

Brendan
Brendan Thank you for the fast answer.
Now another more urgent question pops up.
I protected the code using CRP (wrote the magic number at 0x1fc) and
after a reset in now impossible to communicate to the device via jTag.
Using jLink I obtain:" Error: Received 0xFFFFFFFF as core Id. No
communication with core"
In other words it is a little bit too much protected now....
Is it possible at least do a mass flash erase via jTag?
Otherwise no firmware update are possible, via jTag at least.
Mauro

--- In l..., "Brendan Murphy"
wrote:
>
> --- In l..., "mauroansa" wrote:
> >
> > Hello.
> > I'm looking for a suitable way to protect the code on my lpc2103.
> > The device is programmed using the jLink jtag interface. I Have
> read
> > about the CRP protection, but confused about the use of it and
the
> > effectiveness against ROM boot loader and jTag interface.
> > Can somebody hive me hints or link where to look at?
> >
> > Thanks in advance for help.
> > Mauro Ansaloni
> > CRP is easy enough to use: it's documented in the User Manual of
the
> relevant parts.
>
> As for effectiveness, there's no evidence that there's any problem
> with it, other than (possibly) for LPC2292 parts with bootloader
> version 1.64.
>
> True enough, you need a pretty powerful noise filter to reach that
> conclusion, but I believe it to be acurate.
>
> Brendan
>
--- In l..., "mauroansa" wrote:
>
> Brendan Thank you for the fast answer.
> Now another more urgent question pops up.
> I protected the code using CRP (wrote the magic number at 0x1fc) and
> after a reset in now impossible to communicate to the device via jTag.
> Using jLink I obtain:" Error: Received 0xFFFFFFFF as core Id. No
> communication with core"
> In other words it is a little bit too much protected now....
> Is it possible at least do a mass flash erase via jTag?
> Otherwise no firmware update are possible, via jTag at least.
> Mauro
>
Just the CPR doing its job. See the Usar Manual. If CRP is enabled,
JTAG is disabled (as otherwise it would enable you to read out flash
contents).

The way to recover is to use the ISP to erase and re-flash the device.

CRP is one of those features (a wachdog reset being another) that's
best left until the end, and the rest of the system is fully developed
debugged, before implementing.

Brendan
--- In l..., "Brendan Murphy"
wrote:
>
> --- In l..., "mauroansa" wrote:
> >
> > Brendan Thank you for the fast answer.
> > Now another more urgent question pops up.
> > I protected the code using CRP (wrote the magic number at 0x1fc)
and
> > after a reset in now impossible to communicate to the device via
jTag.
> > Using jLink I obtain:" Error: Received 0xFFFFFFFF as core Id. No
> > communication with core"
> > In other words it is a little bit too much protected now....
> > Is it possible at least do a mass flash erase via jTag?
> > Otherwise no firmware update are possible, via jTag at least.
> > Mauro
> >
> Just the CPR doing its job. See the Usar Manual. If CRP is enabled,
> JTAG is disabled (as otherwise it would enable you to read out
flash
> contents).
>
> The way to recover is to use the ISP to erase and re-flash the
device.
>
> CRP is one of those features (a wachdog reset being another) that's
> best left until the end, and the rest of the system is fully
developed
> debugged, before implementing.
>
> Brendan
>

So if I understand well, the jTag interface is useless at this point.
Rs232 and ISP must be used to erase all... That is some pin have to
be available for ISP, at least during the operation.
No other workaround ?
Unfortunately the rs232 pins are not available on my board at the
moment, so some modifications to the design seem to be mandatory.
Mauro
--- In l..., "mauroansa" wrote:
> So if I understand well, the jTag interface is useless at this
point.
> Rs232 and ISP must be used to erase all... That is some pin have to
> be available for ISP, at least during the operation.
> No other workaround ?
> Unfortunately the rs232 pins are not available on my board at the
> moment, so some modifications to the design seem to be mandatory.
> Mauro
>

I think you've just learned a hard lesson :-(

Can you do a temporary modification to the board to recover it using
ISP?

A redesign mightn't be necessary if you can do this.

The only other way to recover the part (I believe) is to have a re-
progamming feature built into the application running on the part
(e.g. loading through one of the interfaces you do have available).
However, you have to do this (and have it working fully) before you
enable CRP.
> I think you've just learned a hard lesson :-(
>
> Can you do a temporary modification to the board to recover it
using
> ISP?
>
> A redesign mightn't be necessary if you can do this.
>
> The only other way to recover the part (I believe) is to have a re-
> progamming feature built into the application running on the part
> (e.g. loading through one of the interfaces you do have available).
> However, you have to do this (and have it working fully) before you
> enable CRP.
>

Yes, another lesson, learning never ends, isn't it?
I will download Flash Magic and try to unlock the lpc, after some
soldering iron work :-((
But it's not so bad if the board can be saved in this way.
Brendon, thank you again for your valuable help.
Mauro
--- In l..., "mauroansa" wrote:

> I will download Flash Magic and try to unlock the lpc, after some
> soldering iron work :-((

Hi Mauro,

If you do not feel like installing FlashMagic just to recover your
board, you can fetch SILL.EXE from here:

http://tech.groups.yahoo.com/group/lpc2000/files/BootImages/sill.exe

and run it as:

SILL -r comX

Make sure have strapped EINT0 low, and hit SRST before you do this.

As for the protection that CRP offers, you may want to look in here
for an informed view and make your own conclusions without relying on
sales pitch:

http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/crp-security.html

Regards,

Jaya
Thanks Jaya
I'll try both ways in order to get what better fits the needs of an
industrial production of boards that need an unpdate, from time to
time.

--- In l..., "jayasooriah" wrote:
>
> --- In l..., "mauroansa" wrote:
>
> > I will download Flash Magic and try to unlock the lpc, after some
> > soldering iron work :-((
>
> Hi Mauro,
>
> If you do not feel like installing FlashMagic just to recover your
> board, you can fetch SILL.EXE from here:
>
>
http://tech.groups.yahoo.com/group/lpc2000/files/BootImages/sill.exe
>
> and run it as:
>
> SILL -r comX
>
> Make sure have strapped EINT0 low, and hit SRST before you do this.
>
> As for the protection that CRP offers, you may want to look in here
> for an informed view and make your own conclusions without relying
on
> sales pitch:
>
> http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/crp-security.html
>
> Regards,
>
> Jaya
>
--- In l..., "mauroansa" wrote:
>
> Thanks Jaya
> I'll try both ways in order to get what better fits the needs of an
> industrial production of boards that need an unpdate, from time to
> time.
>

FYI: for production we use a bed-of-nails jig that's used for
programming, ICT and functional test. Programming is done by our own
s/w that can parallel program n-units at a time (usually 2 or 4).
Access to the reset and serial port is through test points on the board
(i.e. the serial port isn't actually connected to a connector on the
board). Even if you do use the serial port, you can probably take the
same approach.

Memfault Beyond the Launch