Lpc2000

--- In lpc2000@yahoogroups.com, Charles Manning <manningc2@a...> 
wrote:
>
> 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. 

Thanks for your follow up.

In a debug state there is no system clock activity relevant to JTAG.

The point I was making below is that apart from when JTAG must allow 
some instructions to execute at system speed, the rule does not 
appear to have relevance. Of course there may be other limiting 
factors, but hardly the synchronising one since there is nothing to 
synchronise with.

John Heenan

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.
>