Lpc2000

This posting reports results of a quick investigation into the boot 
loader and CRP (Code Read Protection). It will enable you to confirm 
a factual error by another person asserting supposed evidence to 
contradict claims by Philips. The supposed evidence is not even 
worthy of the label circumstantial evidence.

It is a trivial exercise to step through the boot loader with a 
debugger, but only of course after booting is complete. It is not 
necessary to write or adapt code to dump the bootloader, it is far 
easier to simply step through the bootloader using trivial techniques 
below, which I would have thought would have been worthy of mention 
by anyone with an interest in the bootloader. As to the question can 
you look at the bootloader, certainly you can. It is like asking can 
you look at a naked a woman, yes if you have eyes. As to the question 
can you make independent use or publish in detail what the bootloader 
does, that is a legal question I am unable to answer.

I have a commercial interest in ensuring my code is not stolen, hence 
I am keen to determine if there is any basis for reasonable doubt of 
the claims made by Philips with regard to CRP.

I decided to conduct my quick investigation using tools on hand after 
reading through another bizarre posting announcing web site updates 
concerned with the boot loader and noticing that the updates failed 
to include possible credible explanations I have made that answers a 
question that is posed in the site. This is really irritating and not 
worthy of resources provided by a publicly funded educational 
institution (see below). I have discovered a factual error on the web 
site also. The web site falsely claims the 'first thing' the LPC2148 
bootloader does is to disable the JTAG debug port. The claim is false 
because the boot loader does two 'other things' first. The 'third 
thing' is to assign 0 to VPB register PINSEL2, which simply enables 
port 1 pins solely for GPIO use and cuts off access to JTAG debug and 
to trace. I will pose a question, why make false claims?

The web site domain address used is set aside for a university level 
Australian educational institution publicly funded by tax payers. How 
disappointing. 

The tools I have on hand are a JTAGjet-ARM with its Chameleon 
debugger and an LPC2148 microcontroller. A cheap parallel port 
debugger with GDB would also work. I suspect IAR, Keil and Rowley 
toolsets can also be used.

The LPC2148 user manual informs us the LPC2128 bootloader is 12K long 
and starts at address 0x7FFF D000, although it is remapped. So after 
booting I halted the device, looked at an ARM code disassembly at 
this address, assigned the PC to this address and started stepping. 
There is no reason to assume this is not the remapped start address.

The first three ARM instructions assign 2 to VPB register MAMCR.
The next two ARM instructions assign 3 to VPB register MAMTIM.
The next three instructions assign 0 to PINSEL2 using a SWP command 
and stores the prior value of PINSEL2 in R0

It is trivial to skip over the SWP command to avoid becoming 
disconnected from the JTAG.

The next two instructions swaps 0 with the contents of undocumented 
VPB register 0xE002 C03C into R1.

The first three bits of the old contents of PINSEL2 in R0 are cleared 
when copying into R3 and R3 is stored back into PINSEL2. This 
instruction can also be stepped over to avoid disconnecting the JTAG 
port.

The next instruction jumps to address 0x00FF D1C0, which due to 
remapping probably refers to address 0x0007 D1C0.

Instructions following read the contents of flash memory address 
0x1FC and store it to the read only register (as documented) CSPR 
(Code Security Protection Register) with one exception. If the 
contents of the memory address 0x1FC were 0x43128765 then 0x87654321 
is stored instead. Hence for the LPC2148 there are at least two valid 
code read protection values: 0x87654321 and 0x43218765.

I did not investigate any further, there is no need. The content of 
R0 and R1 have been retained up until I stopped investigating.

There is nothing in any of this sequence that justifies reasonable 
doubt about Philips claims. My own explanations I expressed 
previously still stacks up as possible, namely that if CRP is enabled 
then some possible GPIO pins will not be disabled due to pin P1.26 
being kept low during a reset. In addition just because JTAG may 
potentially get a few cycles before disconnection does not mean an 
internal debug signal JTAG may be asserting will be allowed to act, 
since a write to the CSPR would determine if internal debug signals 
are allowed to act.

It is worth noting that each non sequential bus access adds an extra 
wait state and that if the access involves the VPB then an additional 
three wait states appears to be required.

While I could find out how many cycles are required to make JTAG 
attempt to assert an internal debug signal, I know is not a trivially 
small amount.  For the LPC2xxxx series only one JTAG cycle is allowed 
for six processor clock cycles. Number of cycles required can be 
assessed from examining open source JTAG code. Open source JTAG code 
has its origins in code written by R Longo in 2000 for an Atmel ARM 
processor. Atmel also has JTAG code (under NDA), which it is possible 
to view without signing an NDA.

Even if there was no disablement of an internal debug bus signal 
pending writing to CSPR, it is possible there are simply not enough 
clock cycles avaialble to assert an internal debug signal.

I really don't have time for this. I simply decided to conducted a 
small investigation to check out for myself. It is not worthy to 
discredit claims by Philips using the supposed evidence provided. In 
addition claims that the supposed evidence is the 'first thing' done 
is false.

In addition claims about stack overruns etc in the bootloader are 
irrelevant as all such claims involve using the bootloader outside 
the published specifications. Also there is little part of the 
bootloader specification which states it is designed to have data 
interpreted in human readable form, so why make bizarre snide 
commments about the format of information?

John Heenan