I have new information that may help tip the balance in forming a
consensus. Really I don't want to spend an extra millisecond on this.
The new information I have is that that Jayasooriah is publicly
asserting on a web site that Philips claims with regard to LPC2xxx
series microcontroller Code Read Protection (CRP) are not accurate
due to a single piece of claimed circumstantial evidence that happens
to be bogus as credible circumstantial evidence. The reason the
claimed circumstantial evidence is bogus is due to the following
credible explanations. The claimed evidence in fact enables the JTAG
pins to be used as normal GPIO pins under all reset circumstances if
CRP is enabled and because of a common engineering practice.
Even if the evidence was genuinely circumstantial it is not ethical
or accurate to imply or claim the evidence is authoritative proof of
inaccuracy.
I will try and present the argument in as few words as possible in as
relevant a form as possible. It is important to realise that meaning
of the words 'debug' and 'enable' is contextually driven.
1. JTAG hardware is peripheral hardware whose shared external pin
connections can be enabled (connected) or disabled (disconnected) by
ensuring a specific debug select pin is pulled low on reset. If the
pin is left alone then JTAG pins will not be externally connected by
default on the LPC2148 (due to internal pull-up resistors on Port 1).
JTAG pins can also be disconnected by setting a bit in a pin select
register after reset.
2. There is no theoretical reason why Philips LPC series CRP (Code
Read Protection) will not work as documented. While after reset JTAG
might be enabled and attempting to assert debug signals (a peripheral
engine is on and revving), the internal debug bus signals JTAG may be
attempting to assert may be disabled from acting (the peripheral
engine gears are not engaged). I will assume this is true for the
rest of this posting as it gives a possible concrete explanatory
framework. There is no proof it is not true. Other mechanisms also
have theoretical validity.
3. Quote from Philips manual UM10139 (Volume 1: LPC214x User Manual,
Rev. 01 15 August 2005) page 297:
"Code read protection is enabled by programming the flash address
location 0x1FC (User flash sector 0) with value 0x8765 4321
(2271560481 Decimal). Address 0x1FC is used to allow some room for
the FIQ exception handler. 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"
End of quote
Clearly if CRP is enabled then we don't care any more about JTAG and
we want full access to the JTAG debug pins as GPIO pins EVEN IF THE
DEBUG SELECT PIN HAPPENED TO BE LOW ON RESET and so enabled the JTAG
debug PORT. I could hardly think of a simpler solution to get back
use of the pins as GPIO pins than disabling JTAG pins that may have
unintentionally enabled during reset. Hack attempts will just spin
JTAG uselessly during this time.
There is also another point, it is regarded as sound engineering
practice to disable peripherals that may be enabled and are not
required to save power.
It is important to realise that once CRP is enabled we can now we
don't have to ensure the debug select pin is not pulled low on reset.
I would say very clever Philips and well done.
With regard to actually enabling debug in its totality after deciding
CRP is not enabled, this may simply be a matter of writing to an
undocumented register. The important point is debug in its capacity
to act must be disabled on reset, rather than debug is enabled then
disabled then possibly enabled again. All we have seen is a claim of
evidence that in fact ensures pins can be used as GPIO pins. There is
no harm in partial enablement of debug if there is a missing piece
that prevents debug from acting.
4. Following are two paragraphs from
http://www.cast.com.au/esdk/lpc2/boot-loader.html#LPC[0]. At the end
of the page is a copyright statement "copyright (c) Jayasooriah 2002-
2006 ... updated 01 April 2006". The name Jayasooriah contains a link
to the CV of Jayasooriah: http://www.cast.com.au/jayasooriah/
Start of quote:
"Arising out of my investigation into the boot loader for the above
reasons, I found out that Philips is not accurate in relation to its
documentation of CRP (code read protection) features. For example,
the user manual for LPC2148 clearly states upon reset JTAG debugging
is disabled, and that this is enabled by the boot loader if CRP
feature is not enabled.
"However the first thing the boot loader in LPC2148 does (in a quite
hasty fashion as if to minimise the window of opportunity) is to
disable JTAG debug port. This code is executed for both hardware and
watchdog resets. Why disable JTAG debug port if is indeed already
disabled on reset?"
End of quote.
5. The question has already been answered: get back the GPIO ports.
The evidence is bogus. Jayasooriah appears to be trying to get cheap
shots at by asserting an old and well known vulnerability the
industry has learnt long ago to avoid in new designs.
John Heenan
--- In lpc2000@yahoogroups.com, "brendanmurphy37"
<brendan.murphy@...> wrote:
>
>
> All I can say to this, is "oh, no, not again....."
>
> To the sender of the message below, I'd recommend you do a search
> on "CRP" over the past few months: you'll find plenty there to keep
you
> busy for a while. You'll have to make your own mind up, though, as
> consensus is a bit lacking, to say the least.
>
> Brendan
>
> --- In lpc2000@yahoogroups.com, "croquettegnu" <croquettegnu@>
wrote:
> >
> > Hi all,
> >
> > I would like to know what are the limitations of the CRP
protection
> > because this kind of protection is controlled by the onchip
bootloader
> > so by software and I think that it is perhaps less efficient than
a
> > hardware code read protection feature ...
> >
> > In fact, what are the solutions to access the flash code content
even
> > if CRP is enabled ?
> >
> > I have seen that ATMEL proposes a flash security bit which
disables
> > the JTAG and prevents from flash access. This protection can not
be
> > suppressed except by erasing the flash which is more secure to my
mind
Show quoted textHide quoted text
> > .. Am I worng ?
> >
> > Thanks in advance
> >
>