How is a JTAG used as a debugger?

Question

I understand how JTAG used to be used as boundary scanner (very clean explanation at http://www.fpga4fun.com/JTAG1.html). However I can't see how JTAG these days is used as a hardware level debugger (Somewhat similar to in-circuit emulators).

1. Can some-one explain how JTAG is used as a hardware level debugger?

My assumption is there has to be some extra hardware on-chip which helps in debugging while JTAG merely drives that hardware to get the debug information. If my understanding is correct -

2a. What is that hardware?

2b. Is there a standard for it?

I rather doubt the standard part since all implementations I've seen of JTAG based hardware level debuggers vary from each other.

Finally it's really confusing to have JTAG be called a hardware level debugger whereas the JTAG standard doesn't define anything of the sort. So is there a different name for when JTAG is used for this?

Answer 1

fyi: I'm not sure if I understood you well, and you may already know/understand all I've written below, maybe better than me. Drop me a note, and I'll remove the answer.

1/2a: The hardware used is "just" some extra registers and logic circuits that form/inject additional (orthogonal!) states into the standard JTAG statemachine.

If you understand how the JTAG protocol performs the boundary-scan and how the bitstream is pushed/pulled from the device, you should be able to imagine how is it used to i.e. program on-chip memory banks. Imagine typical daisy-chaining, not between the chips but rather inside-a-chip.

Let's say that device has some programmable persistent memory. With a few more flops and gates, the device forms an extra buffer before or after the JTAG chain of the actual memory:

input -> xflops -> memory -> yflops -> output

let's say that x/mem/y = 16/1024/0. Now, the chain has 1040 bits. The preceding xflops does not directly affect memory nor vice-versa. The xflops might be now linked to the control lines of the builtin internal programmer that drives the memory.

input -> progcmd -> memory -> output

the logic circuit inside the chip can now react to some 16-bit 'magic number' a.k.a. "write command" that will trigger the procedure of writing/erasing of the persistent memory. Any other 16bits values are ignored and device behaves like 1024 r/o data followed by 16bit echo or zeroes.

Ok, so we have simple on-device 'controller' that performs operations on a 'real device'. If you extend the idea with i.e. the controller having states that can control what subdevices are attached to the chain, on the fly:

default chain after reset is:
   input -> progcmd -> output 
if now the controller gets ENABLE_WRITE it attaches MEM to chain
   input -> progcmd -> memory -> output
then controller reacts to WRITE and ABORTs on everything else
   input -> progcmd -> output
controller ges VERIFY, it reattaches MEM again but in READONLY mode
   input -> progcmd -> memory -> output
etc

It is of course just an extra statemachine. In similar way you could do almost any fancy operations, including debugging like freezing, stepping, reading/writing registers etc. But all of this requires tons of extra logic to be built into the chip in question. Actually, it's having several devices in one chip.

2b: Unfortunatelly, I cannot say more, because I'm too green in the subject ;) I know that many manufacturers form their own internal standards, the 'controller's are simply shared between models and sometimes families of chips, but I've not heard of any 'global' standard common between manufacturers.

Answer 2

JTAG is simply a method for interfacing to the chips internals which works alongside the "usual" chip functionality. It's basically a multi-mode (synchronous) serial port.

One of the things this allows is boundary-scan, by accessing the pins directly.

As you surmise, another is to access extra hardware inside the chip. That hardware can be set up to provide (for example) hardware breakpoints, the ability to read registers and arbitrary memory locations, programming internal flash etc. Those are the sorts of things that a debugger application can use.

The JTAG standard provides space for device specific extensions which were always intended for the chip designers to use to provide these sorts of features. There is an attempt to standardise the interface, which covers JTAG and also higher-rate connections to debug hardware, which is called Nexus. However, I've only ever seen Freescale implement it, so it appears to not be as useful a standard as one might hope!

Regarding the terminology, yes, it is probably wrong to call "a JTAG" on its own a hardware debugger. I'm not entirely sure what "a JTAG" is (as used in the question title) - maybe "a JTAG pod" or "a JTAG interface module" would be better?

However phrases like "JTAG debug access" or even "JTAG debugger" (and indeed "JTAG programmer" for those users who are just using it to program the flash) are in common usage (in the UK at least!) and seem to me to be non-confusing, combining as they do the method of interface and the function provided.

Answer 3

The JTAG has an unique interface which enables you to debug the hardware easily in real time. It can directly control the clock cycles of provided controller through software. Therefore, you can put hardware breakpoints in your code execution. You can start, pause, stop execution of code in the hardware as you want.

Whenever JTAG control is set to 1 oscillator clock will be connected to CPU, else CPU will not receive clock and cannot execute any instruction.This way you can control the execution of instructions in hardware.