Lpc2000

--- In lpc2000@yahoogroups.com, Charles Manning <manningc2@a...> 
wrote:
> Non-S parts have independent clocking for the ICEBreaker and the 
JTAG speed is 
> basically as fast as the JTAG/ICEBreaker circuit on the chip will 
handle (ie 
> limited by transmission effects, slew rates etc).
> 
> S parts use the MCLK to deglitch the JTAG lines. The maximum speed 
is 1/6 the 
> MCLK speed.
> 

Thanks for your comments. However the above limitation only applies 
if RTCK is not used.

This is from http://www.arm.com/support/faqip/3732.html

"It is possible to avoid using the RTCK signal shown in the diagram, 
however if the RTCK output is not used, it is required that TCK is 
running at a maximum of 1/6th the system clock frequency if only 1 
JTAG synchroniser is implemented in the system"

Apart from this if takes good board design and connectivity to take 
advantage of the JTAG TCK beyond 1Mhz.

Since we are at this advanced level it may be of interest to point 
out to readers how JTAG uses its bus monitoring to get instructions 
executed and information in and out of memory.

JTAG uses very simple but messy techniques. There is open source 
software that clearly demonstrates these techniques.

JTAG not only read buses it can write to them when the core is under 
debug control. JTAG can pipe a limited range of instructions into the 
JTAG core for execution under JTAG debug control or under subsequent 
temporary non debug system control (a signal is set that places the 
core straight back into debug control).  Since reading and writing to 
memory needs to be carried out at system speed, JTAG pipes in a 
single read to registers or write from registers to execute at system 
speed. 

For writing instructions are piped in prior that load the registers 
with values to write

For reading instcutions are piped in afterwards to make the values 
read into the registers appear on the bus for monitoring.

Very simple, very effective and very messy.

John Heenan


> This is clearly documented in one of the docs on www.arm.com.
> 
> This introduces some interesting quirkiness for devices that start 
on a slow 
> clock and then switch to a faster clock later.
> 
> 
> As for the other points being made: My 2c...
> 
> The JTAG or USB speeds are not the only important issue when it 
codes to 
> debugging speed. One very important factor is where the core-
handling logic 
> is. For example, if the JTAGger is just a "dumb" JTAG probe then a 
lot of low 
> level JTAG transactions need to be passed over the USB link to do 
anything 
> useful. If the JTAG probe instead has ARM core smarts built in, 
then  the 
> traffic can be much higher level. eg. "We hit a break and here is 
the 
> register set". The top-end units (bdi200 and friends) implement the 
whole lot 
> in the debugger.
> 
> A slow but smart JTAGger will knock the pants off a fast but dumb 
one any day.