Lpc2000

Hello,

The boot loader for 2104/5/6 (and I understand earlier versions of boot 
loader for other parts as well) by default catch UND, PRE and ABT type 
exceptions.  These cause the CPSR and LR register to be displayed.

You can verify this by branching any memory location containing 0xffff in 
thumb mode. For parts with boot loader starting at 0xe000 (or 0xd000), "G 
57772 T" (or G 53766 T") should do the trick.   You would get CPRS and LR 
displayed repeatedly as large decimal numbers as the boot loader catches 
the sequence of exceptions.

On the 2292 when I do a "G 57772 T", the boot loader does not display 
anything.  It appears to just hangs and requires a hard reset to come out 
of this.  This begs the question as to what happens to the exception handler.

The reasons for this change would be of concern to anyone who relies on CRP 
feature of the LPCs.  Here are the explanation.

The startup code for 2105 is as follows:

>         ldr     pc, _RST        @ reset entry point
>         ldr     pc, _UND        @ undefined instruction
>         ldr     pc, _SWI        @ software interrupt
>         ldr     pc, _PRE        @ prefetch abort
>         ldr     pc, _ABT        @ data fetch abort
>         nop                     @ reserved
>         ldr     pc, _IRQ        @ interrupt entry
>         ldr     pc, _FIR        @ fast interrupt
>
>_RST:   .word   reset
>_UND:   .word   error
>_SWI:   .word   0
>_PRE:   .word   error
>_ABT:   .word   error
>         .word   0
>_IRQ:   .word   0
>_FIR:   .word   0


Note that UND, PRE and ABT exceptions invoke the "error" handler.

In the case of devices with CRP, given LPC wakes up with JTAG debugging 
enabled, boot loader must disable it CRP is enabled.  It does this by first 
disabling it, and then re-enabling it later if CRP is not enabled.

The code to disable JTAG debugging on the 2292 is as follows:

>         ldr     r2, =PINSEL2
>         mov     r3, #0
>         swp     r0, r3, [r2]

The writing of 0 to PINSEL2 by the third "swp" instruction disables JTAG 
debugging.  One would expect this be done at "start" label.  Thus one would 
expect that JTAG debugging will be disabled on execution the fourth 
instruction after reset, the first being the vector itself.

It appears that boot loader designers consider four instruction cycles too 
long to secure the device from JTAG based CRP exploits.  They considered it 
worth reducing this by just one cycle (to three instructions cycles), at 
the expense of doing away with UND, PRE and ABT exception handler code.

Not only have they done away with handling these exceptions, but they have 
now made the system indeterminate when one of these exceptions do 
occur.  This is because if an UND exception occurred (for example by "G" 
command I referred to above) control is transferred to the second 
instruction instead of the first.

What is of concern is that the boot loader designers have chosen to move 
the code up so that they now disable JTAG in three instructions in stead of 
four.  This must mean that they are aware of JTAG exploits that defeat CRP.

For those skeptics who said that they consider CRP safe until someone posts 
the exploit here in the forum, here is another compelling argument to think 
again.

Jaya 

Send instant messages to your online friends http://au.messenger.yahoo.com