Support user selection of JTAG protocol

[flit]

Allow the user to select between SWD and JTAG, and to control the JTAG scan chain.

• Add a user option to select between SWD or JTAG. Must work with both CMSIS-DAP and STLink.
• Add a command line option to easily select the protocol.
• Add user options to adjust the JTAG device count and IR length. The default IR length should be 4, with 1 device. These options only apply to CMSIS-DAP since STLink uses scan chain auto detection.
• Fully support JTAG protocol with STLink.

[LONGZR007]

I want to be able to select SWD and JTAG from the command line, which simplifies the use of configuration files。

[flit]

Agreed, that would be useful. There is already a dap_protocol option, which can be set from the command line like -Odap_protocol=jtag. But it's not very useful yet, since JTAG doesn't actually work. 😦 But—I'm actually working on it right now.

[w-vlado]

Hi,

Has there been progress on JTAG-only support? In the SoC world, there is actually quite a few SoC designs out there that support only JTAG.

[flit]

No progress, sorry, I've been focusing on other functionality lately.

This is an area that would be great for a contributor to work on.

[tannewt]

Do you think that the DebugProbe interface will need more api than the jtag_sequence() call? I'm interested in jtag support for riscv debug.

[cstrahan]

Any prior art to draw inspiration from during development?

[cstrahan]

Disclosure: I was hoping to ultimately add JTAG over CMSIS-DAP support to probe-rs, and I figured I'd start by studying and contributing to pyOCD. I've recently opened a PR to add this support to probe-rs, so I figured I'd share what I've discovered.

I'll use the STM32F4x as an example. It's an interesting case because there are two TAPs that are connected serially when SWJ-DP is switched to JTAG mode (as it is on POR for this chip) :

23.5 STM32F401xB/C and STM32F401xD/E JTAG TAP connection

The STM32F401xB/C and STM32F401xD/E MCUs integrate two serially connected JTAG TAPs, the boundary scan TAP (IR is 5-bit wide) and the Cortex ®-M4 with FPU TAP (IR is 4-bit wide).

To access the TAP of the Cortex ®-M4 with FPU for debug purposes:

1. First, it is necessary to shift the BYPASS instruction of the boundary scan TAP.
2. Then, for each IR shift, the scan chain contains 9 bits (=5+4) and the unused TAP instruction must be shifted in using the BYPASS instruction.
3. For each data shift, the unused TAP, which is in BYPASS mode, adds 1 extra data bit in the data scan chain.

Note: Important: Once Serial-Wire is selected using the dedicated Arm® JTAG sequence, the boundary scan TAP is automatically disabled (JTMS forced high).

This is interesting for a couple reasons:

• If you're using SWD, then (as implied by the protocol) there's just the one DAP.
• However, if you're using JTAG then you now have two TAPs (one for boundary scan, the other for DAP), and the assumption of one TAP with an IR length of 4 is now incorrect.
• The IDCODE for the DAP depends on choice of SWD or JTAG

In an attempt to find some prior art for specifying these details in config, I looked to openocd; there you will find this target config: stm32f4x.cfg

These parts (relating to JTAG) stand out:

#jtag scan chain
if { [info exists CPUTAPID] } {
   set _CPUTAPID $CPUTAPID
} else {
   if { [using_jtag] } {
      # See STM Document RM0090
      # Section 38.6.3 - corresponds to Cortex-M4 r0p1
      set _CPUTAPID 0x4ba00477
   } {
      set _CPUTAPID 0x2ba01477
   }
}

swj_newdap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID
dap create $_CHIPNAME.dap -chain-position $_CHIPNAME.cpu

if {[using_jtag]} {
   jtag newtap $_CHIPNAME bs -irlen 5
}

set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME cortex_m -endian $_ENDIAN -dap $_CHIPNAME.dap

You can see how the DAP is configured for either protocol (with the respective IDCODE), and the boundary scan TAP is added only if JTAG is used.

At this point, I don't have a concrete suggestion for how the user should specify these options, though it's something I'll have to eventually figure out to wrap up my work on probe-rs. Regardless, I hope some of these details will be of help to you.