Re: CRP exploits using JTAG

Started by Jayasooriah February 8, 2006
Dominic,

My apologies. I misread nSRTS as nTRST, and I incorrectly referred to 
EmbeddedICE-RT macrocell as ETM -- I did not meant to discuss ETM at all.

I have no experience with EIRM debugging myself and what I am raising here 
is mainly based on scanning ARM7-DTMI-S Technical Reference Manual (TRM) 
(Revision 4) for the purposes of this discussion :)

At 03:19 09/02/2006, lpc2000@lpc2... wrote:
>    Date: Wed, 8 Feb 2006 16:58:45 +0100
>    From: Dominic Rath <Dominic.Rath@...>
>Subject: Re: re: CRP exploits using JTAG
>...
> > 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.
>No. This behaviour has been confirmed by someone from Rowley.

I was quoting the above from 5.12.1 of the TRM.  Note that it also says in 
this section that when the boundary scan interface is not used, you can tie 
DBGnTRST input low.  Is this what your OpenCD tool does?

>...
>On the LPCs, driving nRESET low keeps the TAP controller in reset, too.
>Period.

I heard you the first time, but where would one find this information? If 
it was  established by experimentation, how was nTRST driven?  LOW then 
HIGH or just LOW?

>Just because you believe that this is the reason
why Philips dumped the
>exception vectors doesnt necessarily mean that there's a way to cut the
>number of TCK cycles down.

IMHO we (you and I) cannot conclusively say one way or another.  Only the 
designers can, and they have chosen not to.

What they have said, however, is:

"EmbeddedICE logic ... allows instructions to execute at a slow debug speed

or at fast system speed"

"The scan chains that are around the core for production test are reused in

the debug state ..."

If I had my JTAG to play with (and the time to play), I would try the 
following while nRESET is held low:

a) select SCAN_N instruction
b) select chain #1 (later 5,6,7,9-15 and so on)
c) select INTEST instruction
d) scan DBGBREAK bit (for chain #1)

and then see how long it then takes to enter debug mode in halt state upon 
releasing nRESET.

Jaya

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

An Engineer's Guide to the LPC2100 Series

Dominic has mentioned this and trying to set the core to break from
reset will not work with some ARM7 cores, the two i know of are the
LPC and the STR7.
The jtag cell and ice logic are both reset when the reset (nSRT) are
asserted, this is done internally without touching TSRT.

Your method is used (see below) but will not work in the case of the
LPC/STR7 - it has been tried.

The behaviour you mention is used on some arm cores (mainly ARM9) to
set a breakpoint at address 0 and perform a hard reset.

Regards
Spen

--- In lpc2000@lpc2..., Jayasooriah <jayasooriah@...> wrote:
>
> Dominic,
> 
> My apologies. I misread nSRTS as nTRST, and I incorrectly referred to 
> EmbeddedICE-RT macrocell as ETM -- I did not meant to discuss ETM at
all.
> 
> I have no experience with EIRM debugging myself and what I am
raising here 
> is mainly based on scanning ARM7-DTMI-S Technical
Reference Manual
(TRM) 
> (Revision 4) for the purposes of this discussion
:)
> 
> At 03:19 09/02/2006, lpc2000@lpc2... wrote:
> >    Date: Wed, 8 Feb 2006 16:58:45 +0100
> >    From: Dominic Rath <Dominic.Rath@>
> >Subject: Re: re: CRP exploits using JTAG
> >...
> > > 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.
> >No. This behaviour has been confirmed by someone from Rowley.
> 
> I was quoting the above from 5.12.1 of the TRM.  Note that it also
says in 
> this section that when the boundary scan interface
is not used, you
can tie 
> DBGnTRST input low.  Is this what your OpenCD tool
does?
> 
> >...
> >On the LPCs, driving nRESET low keeps the TAP controller in reset, too.
> >Period.
> 
> I heard you the first time, but where would one find this
information? If 
> it was  established by experimentation, how was
nTRST driven?  LOW then 
> HIGH or just LOW?
> 
> >Just because you believe that this is the reason why Philips dumped the
> >exception vectors doesnt necessarily mean that there's a way to cut the
> >number of TCK cycles down.
> 
> IMHO we (you and I) cannot conclusively say one way or another. 
Only the 
> designers can, and they have chosen not to.
> 
> What they have said, however, is:
> 
> "EmbeddedICE logic ... allows instructions to execute at a slow
debug speed 
> or at fast system speed"
> 
> "The scan chains that are around the core for production test are
reused in 
> the debug state ..."
> 
> If I had my JTAG to play with (and the time to play), I would try the 
> following while nRESET is held low:
> 
> a) select SCAN_N instruction
> b) select chain #1 (later 5,6,7,9-15 and so on)
> c) select INTEST instruction
> d) scan DBGBREAK bit (for chain #1)
> 
> and then see how long it then takes to enter debug mode in halt
state upon 
> releasing nRESET.
> 
> Jaya
> 
> PS:
> 
> 
> Send instant messages to your online friends
http://au.messenger.yahoo.com
>
	
Hello Jaya,

On Wednesday 08 February 2006 23:35, Jayasooriah wrote:
> Dominic,
>
> My apologies. I misread nSRTS as nTRST, and I incorrectly referred to
> EmbeddedICE-RT macrocell as ETM -- I did not meant to discuss ETM at all.
>
> I have no experience with EIRM debugging myself and what I am raising here
> is mainly based on scanning ARM7-DTMI-S Technical Reference Manual (TRM)
> (Revision 4) for the purposes of this discussion :)
>
> > > 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.
> >
> >No. This behaviour has been confirmed by someone from Rowley.
>
> I was quoting the above from 5.12.1 of the TRM.  Note that it also says in
> this section that when the boundary scan interface is not used, you can tie
> DBGnTRST input low.  Is this what your OpenCD tool does?
The "No" was refering to "You appear...".
nTRST would allow you to reset the test logic, without affecting the operation 
of the core, but as you correctly observed this can be achieved using 5x TCK 
with TMS high, too. My OpenOCD allows you to specify whether nTRST is 
available at all, and if it should be used - during normal (debug-)operation, 
nTRST has to be driven high. Tying DBGnTRST low would disable the TAP.

> >...
> >On the LPCs, driving nRESET low keeps the TAP controller in reset, too.
> >Period.
>
> I heard you the first time, but where would one find this information? If
> it was  established by experimentation, how was nTRST driven?  LOW then
> HIGH or just LOW?
Tested by driving nRESET low. Driving it Low and then High lets the
target 
run, and that's not what we want.

> >Just because you believe that this is the
reason why Philips dumped the
> >exception vectors doesnt necessarily mean that there's a way to cut the
> >number of TCK cycles down.
>
> IMHO we (you and I) cannot conclusively say one way or another.  Only the
> designers can, and they have chosen not to.
>
> What they have said, however, is:
>
> "EmbeddedICE logic ... allows instructions to execute at a slow debug
speed
> or at fast system speed"
This refers to the way ARM7/9 cores are debugged. Slow means that the
core is 
clocked by the TAP controller (one core cycle for every tck spent in 
Run-Test/Idle when Scan Chain 1 is selected), while fast means that the core 
resynchronizes back to system speed, executes the instruction (usually a 
load/store to access memory), and reenters debug state. "Fast" doesn't
mean 
that it's "faster" to execute instructions at system-speed than at 
debug-speed.

> "The scan chains that are around the core for
production test are reused in
> the debug state ..."
>
> If I had my JTAG to play with (and the time to play), I would try the
> following while nRESET is held low:
>
> a) select SCAN_N instruction
> b) select chain #1 (later 5,6,7,9-15 and so on)
> c) select INTEST instruction
> d) scan DBGBREAK bit (for chain #1)
When nRESET is held low, you can't even shift the IDCODE out of the
device. 
The TAP doesn't react at all. When shifting an instruction into the device, 
b0001 should be shifted out (it is when nRESET is high), but when nRESET is 
low, only zeroes appear at TDO (could be high impedance, too, but that's what 
my interfaces return).

> and then see how long it then takes to enter debug
mode in halt state upon
> releasing nRESET.
>
> Jaya
>
> PS:

Regards,

Dominic