JTAG <-> Serial Wire Debug (SWD) Connections

Posted on by crackingcontraptions_3voi0v

There are five objects in the debug toolchain:
IDE -> gdb-for-target-architecture  -> debugger-hw-server -> debugger-hw -> target-uC.

Here are some examples.

  1. IDE:  e.g. Atmel Studio 6;  Eclipse; IAR
  2. gdb-for-target-architecture: e.g. gdb-earm; gdm-nordic
  3. debugger-hw-server: e.g. st-util
  4. debugger-hw: e.g. AVR JTAGICE; SEGGER
  5. target-uC: e.g Atmel at2560, STM32F4xx

Items 3,4 and 5 are usually proprietary and supplied by the manufacturer of the target-uC (5).  A proprietary toolchain can cost $3K and way above.  It can be hobbled to limit how long it can be used for, or how big a program it can generate, or some other annoyance. 

There has been an open source attempt to standardize them, so the same IDE can be used to program and debug multiple different targets.  i.e. you don’t have to learn, and simultaneously use a bunch of different IDEs for each processor you are working with.  For example,  if you are writing code to communicate between a PC and and ARM chip then you would normally have to have two IDEs open – one for each host.

GDB with GDB Server

Architecture

So what do these five parts do, and how do they talk to each other?


Working backwards from the chip:

The debugger-hw uses one, or more “standards” like JTAG, or SWD, for connecting to the chip.  The physical pinout of each debugger-hw box seems to be different, and chosen according to the needs of the board layout person.  So Atmel provides a “standard” JTAG cable.  But  to connect an Atmel-JTAG to an ST-uC you have to build a squid cable.  But why are not common flavors of squid cable for for sale?  Tag Connect

Item 2 (gdb-for-target) talks to 3 gdb-hw-server using one of a variety of protocols.  Examples are J-Link, GNUARM J-Link; GNUARM-OpenOCD; OpenOCD via pipe; TCP-IP; …   I have no idea what the strengths or weakness of each is.  TCP-IP allows the debugger and the debuggee to be hosted on different physical machines.   gdb-for-target has a command line interface (CLI) for unix aficionados. 
IDEs are normally source-level graphical debugging systems.  They generate CLI commands themselves and send them to gdb, catch the results, and display them graphically.   i.e. A cursor moves over the source code to indicate the current program counter.

My intuition (unconfirmed by evidence) is that gdb-for-target-architecture is just a generic (open source?) gdb that has been given an architecture specific config-file, so it understands register names and positions, memory organization and so forth.

There also appears to be a generic open-source debugger-hw-server, but it isn’t well-supported and I find it hard to understand how to set it up for a particular debugger-hw



My notes on making a debug toolchain


This is how you turn the Atmel ICE JTAG debugger into an STM32F4xx SWD debugger.
I used these two documents to figure out the pin assignments.

  1. USER MANUAL for Discovery kit for STM32F407/417 lines (page 14)
  2. Atmel ICE Physical Interface

First abortive attempt

So I connected it up as per the numbers, like this.
But these connections make no sense to me based upon what is written on the back of the 10-pin JTAG connector.
For example SWDIO on the SWD is linked to JTAG pin-2 which is GND.

I think my problem stems from the 10-pin AVR JTAG and the 10-pin ARM JTAG being different.

Second attempt – still under development

SWD ARM JTAG AVR JTAG
1 Vdd 1 Vcc 1 TCK
2 SWCLK 2 TMS 2 GND
3 GND 3 GND 3 TDO
4 SWDIO 4 TCLK 4 VTref ?
5 NRST 5 GND 5 TMS
6 SWO 6 TDO 6 RES
7 RTCK 7 Vcc
8 TDI 8 NC
9 GND 9 TDI
10 RESET 10 GND
So maybe the connections should look like this.

1 thought on “JTAG <-> Serial Wire Debug (SWD) Connections”

  1. David Carkeek says:

    What I don't understand is that JTAG has separate Input (TDI) and Output (TDO) signals but the SWD interface appears to have a Bidirectional signal (SWDIO). If SWDIO is bidirectional I think it's a show-stopper unless the JTAG-ICE has a mode that allows one of the pins to become bidirectional for compatibility with SWD.

    http://en.wikipedia.org/wiki/Jtag
    http://en.wikipedia.org/wiki/Joint_Test_Action_Group#Serial_Wire_Debug

    "Serial Wire Debug (SWD) is a 2-pin electrical alternative JTAG interface that has the same JTAG protocol on top. It uses the existing GND connection. SWD uses an ARM CPU standard bi-directional wire protocol, defined in the ARM Debug Interface v5. This enables the debugger to become another AMBA bus master for access to system memory and peripheral or debug registers. Data rate is up to 4 Mbytes/sec at 50 MHz. SWD also has built-in error detection. On JTAG devices with SWD capability, the TMS and TCK are used as SWDIO and SWCLK signals, providing for dual-mode programmers."

    It looks like already have that figured out. TMS becomes SWDIO.

    http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0314h/Chddgbee.html
    "2.2.3. JTAG and SWD interface
    The external JTAG interface has four mandatory pins, TCK, TMS, TDI, and TDO, and an optional reset, nTRST. JTAG-DP and SW-DP also require a separate power-on reset, nPOTRST.
    The external SWD interface requires two pins:
    a bidirectional SWDIO signal
    a clock, SWCLK, which can be input or output from the device.
    The block level interface has two pins for data plus an output enable that must be used to drive a bidirectional pad for the external interface, and clock and reset signals. To enable sharing of the connector for either JTAG or SWD, connections must be made external to the SWJ-DP block, as shown in Figure 2.6. In particular, TMS must be a bidirectional pin to support the bidirectional SWDIO pin in SWD mode. When SWD mode is used, the TDO pin is expected to be re-used for Serial Wire Output (SWO). You can use the TDI pin as an alternative input function."

    Yes, I think you have it connected correctly.

Leave a Reply