Lpc2000

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