Lpc2000

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
> > .. Am I worng ?
> > 
> > Thanks in advance
> >
>