Lpc2000

Dominic,

I believe you are not distinguishing between JTAG reset and LPC reset.

JTAG operations are carried out using the TAP (Test Access Port) 
controller.  This TAP controller can be forced to its "reset" state by 
driving signal nTRST LOW or by pushing a sequence through TMS for a given 
number (I recall 5) of TCKs.

To use the boundary scan interface, nTRST must be driven LOW and then HIGH 
again. You appear to have held it low, and hence your observations.

Driving nTRST HIGH does not mean you have also to drive nRESET HIGH.  The 
TAP controller can be accessed with nRESET held low, and this how "boundary 
scanning" is used for debugging in the days before ETM (Embedded Trace 
Macrocell).

One discovers chains, and instructions that operate on these chains, by 
scanning the TAP controller.  The ETM (understandably) may be held in reset 
state while nRESET is low.  However this appears not to be the case for for 
chain 1 or any other chains not covered by IEEE specifications.

By its nature JTAG implementations typically do no more than what they are 
expected to do in the sense the designers do not worry about what happens 
if instructions or data other than what is expected is shifted in.  So it 
is very hard to say what can and cannot be done if we go beyond public 
instruction set.  Not being able to "fuse off" JTAG port is its biggest 
drawback in the context of CRP.

I would not assume CRP is safe just because nobody has posted a JTAG 
exploit in this forum.  I would enumerate threats, then assess each threat 
in terms of risks and costs.  Putting your product in student laboratories 
is a very different ball game to sending them out to some country that does 
not have enforceable copyright laws.

IMO, JTAG window has too large an attack surface area to consider it safe 
for most (if not all) of the requirements I have had to evaluated.  Adding 
to this, the fact that boot loader code is closed and comes with no 
certification of any kind makes CRP no more than "child proofing" as one 
poster put it.

Regards

Jaya

PS:  I bet you can find ways to reduce the 79 TCK requirements by taking in 
to account the state the shift registers before you shift but this is not 
why I would not take the 79 TCK requirement seriously.  If you needed this 
many cycles then it does not make sense to reduce the window of opportunity 
by one jump instruction at the expense of exception handling, as was done 
on the 2292.

--- In lpc2000@yahoogroups.com, Dominic Rath <Dominic.Rath@...> wrote:
 > Philips stated it, but only after several reports in this group, in the
 > "[lpc2000] destroyed LPC2138 via software" thread (though with the usual
 > amount of unclarity, stating that jtag was disabled after reset, and only
 > reenabled by software ;)).

 > Before that, I found it out by experiment. Force nSRST low, and you can 
shift
 > into the device whatever you want, without any effect. Also, the content of
 > the EmbeddedICE registers is reset, so the target wont break on a 
previously
 > set breakpoint (other ARMs support this).
 >
 > > >Test logic comes out of reset in Test-Logic-Reset. From there, you 
have to
 > > >go to Shift-IR to select the SCAN_N instruction, that's 5 TCK cycles. The
 > > >IR register is 4 bits long, but the last bit is scanned when moving 
out of
 > > >Shift-IR, so you spend 3 ticks shifting bits into the IR reg. From there,
 > > >you have to move to Shift-DR to select the EmbeddedICE scan chain. This
 > > >takes 7 TCK cycles. The SCAN_N register is 4 bits long, so you shift 3
 > > >bits. Back to
 > > >Shift-IR to select INTEST takes 8 ticks. 3 ticks for the instruction. 7
 > > >Ticks back to Shift-DR. The EmbeddedICE scan chain is 38 bits long,
 > > >requiring a shift of 37 cycles. The synchronization latches only open in
 > > >Run-Test/Idle, so you have to move there in 5 ticks, plus one tick in
 > > >R-T-I for the debug request to register.
 > > >5 + 3 + 7 + 3 + 8 + 3 + 7 + 37 + 5 + 1 = 79 TCK cycles.
 > >
 > > I can  follow your logic here, but 79 ticks seems too far off the mark
 > > compared to 34 and 49 above.  Have out missed out something?
 >
 > These 79 TCK cycles are the minimum necessary to write the Debug control
 > register when coming out of Test-Logic-Reset. You just can't do it with 
less
 > TCKs.
 >
 > >
 > > Jaya
 >

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