Lpc2000

On Friday 07 October 2005 13:45, John Heenan wrote:
> The 'max TCK=1/6 MCLK if RTCK not used' rule only appears to apply if
> the core is not in a debug state.
>
> If the core is placed in a debug state, such as at a breakpoint,
> there is no system clock to syncronise with!

That is probably not true. There is still an MCLK, but it is just not being 
used to currently execute the core, however it is still there. Various 
peripherals etc can still be running off MCLK. Without it SDRAM etc will die. 
All register to RAM transfers are done at full clock speed.

I'd have to read it all up again, but from my understanding, the 1/6 rule is 
used by the deglitching logic on the outside of (ie. JTAG side of) the 
ICEBreaker. There is nothing I have read to suggest that the deglitcher turns 
off during debug, so I assume the clock is still there and used.

As for RTCK, this is academic. A synchronous deglitcher will essentially 
throttle the RTCK speed to 1/6 anyway.

>
> While in a debug state JTAG will need to execute some one-at-a-time
> piped instructions at system speed before returning straight into a
> debug state (explained in prior posting). This may be an issue if
> JTAG is polling for a return to debug state. However there is a hell
> a lot work carried out by JTAG debuggers outside this.

Very much agree and that is why I made the point of dumb vs smart probes,

Consider the case of writing some data into RAM:
Smart probe:
  Host: Write these bytes to address xxx"
  Probe: Done
Dumb probe:
  Host: Read this jtag register
  Probe: Here it is
  Host: Now Write this jtag register
  Host: Now Run-test-idle
  <above sequence for n times>
  Host: Read status
  Probe: Here it is
  <above until the core returns to debug state>

The dumb probe scenario has had to shovel a lot of data through the host's 
drivers and control application. This adds a lot of latency. Smarter probes 
can handle the core interaction with no help from the host and can process 
the data a lot faster.

Even while the core is running, there is a lot of stuff that should be going 
on monitoring the state of the device and servicing the debug communications 
channel (DCC). Very few, if any, of the low end JTAG devices do this properly 
and I have not seen any that support DCC - probably for that reason [I admit 
I have not looked hard]. The "smart" probes will handle all the core state 
(including DCC handling) in the probe. "Dumb" probes that send bit wiggles or 
low-level JTAG commands over the USB cannot do an effective job of handling 
DCC etc.

IMHO a good debugger will spend all its running time reading the debug status. 
It should be able to read this approx 20-100k times per second. That can make 
a DCC that transfers probably around 100kbytes per second.

A "dumb" probe can probably only read the status 1k times per second and can 
probably manage no more than 4 or 5 kbytes per sec over the DCC channel.

Most of the performance in a debugger is linked to its ability to do higher 
level activities autonomously. While the JTAG clock is obviously a factor it 
is far from being the most important factor.