Understanding JTAG protocol waveform

[mindentropy]

Hi,

Setup:

I have connected an Olimex ARM-USB-Tiny-H to a STM32F407G-DISC1 board. The board has a STM32F407VG chip.

Problem
I am trying to under the JTAG protocol. I requested IDCODE and I have got the right output as I have verified the data from the datasheet. The problem is I am confused with the waveform. I have captured this waveform in my LA.



In the waveform I see 10 bits transferred to TDO in the chain. The scan chain of the STM32F407VG shows two IPs in the scan chain, a Boundary Scan TAP of length 5-bit wide and Cortex M4 TAP of 4-bit wide as below.



How is my TDO having 10 bit sent out instead of 9 bits as my IR total scan chain length is only 9 bits? Any help would be greatly appreciated.

[RoGeorge]

See if reading this clarifies it:
https://www.fpga4fun.com/JTAG.html

[ataradov]

This part does not seem to do anything with IDCODE specifically. Without bigger context, it is hard to tell what they are doing here.

Normally to get IDCODE you simply do the logic reset and shift the DR. IDCODE is selected by default after the reset. This lets you identify the full chain.

You can issues IDCODE IR, of course, but this is not what is going on here.

[mindentropy]

@ataradov I have attached the capture spreadsheet. Does that help?

I have run the detect command in urJTAG.

[ataradov]

Seeing the original logic analyzer may be more useful.

It is hard to tell what exactly is going on here. My best guess is this. The first two long sequences for the IR and DR shifts are attempts to determine the the length of the IR and DR chain. Although it looks strange and unusual.

The actual ID codes are read in the last part. You can see it do exactly what I have described - do TRST, which selects IDCODE of all devices in the DR chain. Then scan the DR chain to sequentially shift out all the ID codes.

Although in this case it shifts way more than necessary. Usually what you do is shift 0s in and read the data in 32-bit increments. a valid IDCODE always has 1 in the LSB. So, by shifting 0s, as soon as you get a 32-bit value with 0 in the LSB, you know you reached the end of the chain.

Now you know the number of devices in the chain. Individual IR lengths can be determined by the lookup table (or BSDL file) from the IDCODE. Or you can use BYPASS instruction to probe the IR length of each device automatically.

Also, as a general advice - forget about JTAG on ARM devices. Use SWD, it is way more efficient and easier to use.

[mindentropy]

It is hard to tell what exactly is going on here. My best guess is this. The first two long sequences for the IR and DR shifts are attempts to determine the the length of the IR and DR chain. Although it looks strange and unusual.

Yes you are right. I rechecked the output of the "detect" command and I found that it prints the IR length. Made me wonder how it did as I did not provide any IR length manually. Looking at the code there is some way to detect the IR length and that trace might be showing that.

The actual ID codes are read in the last part. You can see it do exactly what I have described - do TRST, which selects IDCODE of all devices in the DR chain. Then scan the DR chain to sequentially shift out all the ID codes.

Ok. I was confused with the TRST which selects IDCODE register. I thought an instruction needs to be loaded in the IR register and then the DR needs to be read and I was trying to find out where the instruction is loaded in the trace. I reread the TI documentation on the IDCODE and the following is written:


Also, access to the device identification register should be immediately available, via a TAP data-scan operation, after power-up of the IC or after the
TAP has been reset using the optional TRST* pin or by otherwise moving to the Test-Logic-Reset state. The bit code of this instruction is defined by the vendor.

Although in this case it shifts way more than necessary. Usually what you do is shift 0s in and read the data in 32-bit increments. a valid IDCODE always has 1 in the LSB. So, by shifting 0s, as soon as you get a 32-bit value with 0 in the LSB, you know you reached the end of the chain.

Now you know the number of devices in the chain. Individual IR lengths can be determined by the lookup table (or BSDL file) from the IDCODE. Or you can use BYPASS instruction to probe the IR length of each device automatically.

Let me check this in the trace and code and try to understand and get back.

Also, as a general advice - forget about JTAG on ARM devices. Use SWD, it is way more efficient and easier to use.

This is purely to understand JTAG protocol and is learning exercise. It would be a different matter if I am looking at production.

[mindentropy]

@ataradov: What is the value of IDCODE instruction?

[ataradov]

It is device-dependent, there is no standard  The only thing that is defined by the standard is that BYPASS must be all 1s.

In the case of ARM, IDCODE is 0b1110. But I don't know what is the value for the ST boundary scan part.

[RoGeorge]

This is purely to understand JTAG protocol and is learning exercise.

Starting from an MCU and counting pulses is not the best way to understand JTAG.

Read that link from fpga4fun.  Click the button at the end of the page to advance to the next.  That's the briefest JTAG read I know, read all 4 pages.
https://www.fpga4fun.com/JTAG.html
https://www.fpga4fun.com/JTAG1.html
https://www.fpga4fun.com/JTAG2.html
https://www.fpga4fun.com/JTAG3.html
https://www.fpga4fun.com/JTAG4.html

Those pages might seem offtopic at first, but read them, it's all you need to know in order to understand JTAG.  Look careful and understand the state machine described there.

That state machine diagram, and the fact that  one or more JTAG chips can be chained between TDO and TDI in a JTAG chain, is all it's needed to make sense of the pulses seen with the LA.

Each chip has it's own specific registers, aside from the mandatory ones specified by the JTAG state machine, and those are described in the datasheet.

To make sense of the pulses and decode the JTAG communication, you'll have to know the following:
- the architecture of the JTAG state machine, and how it works
- the number and the types of the JTAG chips in the given JTAG chain
- the datasheet description of any specific registers, from all of the chips chained in the JTAG chain
- the state in which the state machine might be at the moment you start recording the signals TDI TDO TMS TCK (all are needed for a decode)

[RoGeorge]

How is my TDO having 10 bit sent out instead of 9 bits as my IR total scan chain length is only 9 bits?

Not sure I understood the question, but you need to shift one more time, because you have 2 devices in the JTAG chain.  When many JTAG devices are chained, you need to shift the data through all of them, until the data arrives to your JTDO.

Between each TDI-TDO, there is a flip-flop (FF).  When many TDI-TDO are chained, the FFs will form a shift register.

You have 2 devices in your JTAG chain, so you have 2 FF, like this:
JTDI ->
TDI(boundary) -> FF(boundary) -> TDO(boundary) ->
TDI(M4) -> FF(M4) -> TDO(M4) ->
JTDO

You'll need one more clock edge in order to push out the last bit of the first IR (boundary TAP) through the FF(M4).

Thinking only about the boundary TAP, on the 5th clock that reads its 5 bits long IR, the 5th IR bit will be shifted out, and because the FF(M4) is in the way, the 5th IR bit of the boundary TAP is not yet seen at JTDO.  One more clock is needed to push it through the FF(M4).

If it were to have yet another device inserted in the JTAG chain, say an external flash memory with JTAG (or something else with JTAG) additionally to the 2 devices you already have (boundary TAP and M4 TAP), like this:
JTDI ->
TDI(boundary) -> FF(boundary) -> TDO(boundary) ->
TDI(M4) -> FF(M4) -> TDO(M4) ->
TDI(flash) -> FF(flash) -> TDO(flash) ->
JTDO

then you would see yet another extra clock, needed to shift the data through the FF of the 3rd device, the FF(flash).