CuVoodoo

the sorcery of copper

User Tools

Site Tools


jtag

JTAG is a technology to test integrated circuits, mostly micro-controllers and CPUs. It allows to do hardware debugging: read/write memory, control I/Os, and debug running code.
SWD is a more modern version of JTAG and only requires 2 pins instead of 4[+1].
SWJ is a combination of Serial Wire Debug (SWD) and JTAG. But they provide the same logical functions.

On one side this functionality must be included in the target device. The Debug Port is often called JTAG-DP for JTAG and SW-DP for SWD. SWJ capable device include and often combine both, as the SWD signal pins SWDIO and SWCLK re-use the JTAG signal pin JTMS and JTCK (backwards compatible). Most 32 bits micro-controllers and SoCs have one of both (or both).

On the other side you need a SWJ adapter so the host can speak to the device using the JTAG and/or SWD protocol. SWJ adapters can go from cheap (<5$) to expensive (>1000$), depending on the quality of the hardware and software.

SWJ adapters

These are the main SWJ adapters I am using.

The ST-LINK/V2 is from STMicroelectronics, and is very convenient to flash their STM8 and STM32 micro-controllers, such as the STM32 F1 series. It supports JTAG, SWD, and SWIM (for STM8).

These SWJ adapters are based STM32F1xx ARM Cortex M3 micro-controllers. And ironically enough I in turn use them to program and debug STM32F1xx ARM Cortex M3 micro-controllers.

First add the rules for normal users to be able to access the device (udev rule based on the VID and PID shown by lsusb). This has only to be done once, before the device is plugged in to be used:

echo -n 'ST-Link V2 SWJ adapter' | sudo tee -a /etc/udev/rules.d/60-st-linkv2.rules
echo -n 'ATTR{idVendor}=="0483", ATTR{idProduct}=="3748", MODE="0666"' | sudo tee -a /etc/udev/rules.d/60-st-linkv2.rules
sudo udevadm control --reload-rules

To connect to STM32F1xx ARM Cortex M3 micro-controllers I use OpenOCD:

openocd --file interface/stlink-v2.cfg --file target/stm32f1x.cfg
 
Open On-Chip Debugger 0.10.0-dev-00189-g554313b (2016-01-12-10:52)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.534945
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints

I am using cheap clones.

case front case back internal front internal back

This is a complete rip-off of the ST-LINK/V2. It comes in the same box, with the same cables, the enclosure is the same, even the board name has been taken over (MB936), but the board isn't the same. The BOM doesn't match with the original.
The original adapter comes with ESD protection, protection resistors, and a transceiver to allow operating with target signal levels of 1.65V to 5.5V. This is completely missing on the clone since the connector pins are directly connected to the micro-controller. Thus it only supports target signal levels of 3.3V and sometimes 5V since the pins are 5V tolerant.

For $9 you can't expect more, and if you want a cheap adapter I recommend the other ones (see below).

These adapters come in a small dongle sized aluminium case. They supports SWD, and SWIM (for STM8), but not JTAG. Also the RST signal (required for SWIM) is not controllable as SRST in SWD mode (at least not by OpenOCD).

For less than $2, they are the cheapest SWD programmer you can find. I also like to use them as development board when I just need a USB dongle with just a few signals (up to 4).

Numerous board variants exist and it is hard to know what you will get. Always check the pinout on the aluminium case and on the PCB since this also varies. Here are the board variants I got, in chronological order.

I've reversed the schematic for this board.

One trick to get this ridiculously low price is to use STM32F101 micro-controllers. Compared to the STM32F103 micro-controllers they offer less functionalities, like USB … yet this is a USB dongle! Well this is because these micro-controllers use the same die, but if not all STM32F103 feature tests pass after production they get packages as STM32F101, but it seems that USB still works well enough. At least this is my guess. It would be interesting to check if the other STM32F103 peripherals normally not present on the STM32F101 work as well, but I wouldn't rely on these. After all, they are probably marked as STM32F101 for a good reason.
Similarly the STM32F103C8 is only rated having 64 kB of flash because it didn't pass the flash test, compared to the 128 kB for the STM32F103CB, but they very often have more (you can verify by read/writing and check for errors).

One other nice trick they used is to have twos LEDs on the same pin (PA9):

  • when the pin is set to output high, only one LED lights up
  • when the pin is set to output low, the other LED light up
  • when set to input floating, both LEDs are off
  • when PWM output is used, you can mix the two colors (red and blue) quite well due to the persistence of vision (also because the LEDs are next to each other and the small hole in the case is in the center).

alternative pinout

From the outside this looks very similar to the previous one, except that the connector pinout is very different (except for power) and there is only one LED.
No markings are on the board.

This one has an “M” logo instead of the ST logo, probably corresponding to the “MX-LINK V2” marking on the board.

SWDIO/SWCLK swap

This variant uses an STM32F103. It seems this micro-controller got so popular that it is now cheaper than the STM32F101 (with less features). The annoying details of this variant is that the SWDIO and SWCLK signal described on the pinout engraved in the aluminium case are swapped. This shows again the importance of also checking the pinout on the board itself, else you can waste a couple of hours debugging.

QFN

This variant uses an STM32F103 in the UFQFN-48 package. This is just a couple of cents cheaper than the more traditional TQFP-48 package, but this is enough en mass to change the footprint on the board.

Instead on an STM32F103, this dongle uses a CKS CKS32F103 (sometimes CS32F103) (chinese datasheet, datasheet translated to english). I've seen pin compatible alternatives (ST STM8S003 vs Nuvoton N76E003), even architecture compatible (ST STM32F103 vs GigeDevice GD32F103), but they always had some differences (architecture, electrical pin properties, registers, …). The CS32F103 seems like a complete clone of the STM32F103 (exact same pinout, architecture, registers). So far I could not not see any difference (I tested flash, USB, SWD). I guess this micro-controller is so popular that it was just a question of time until it was ripped-off. To check if this is a complete clone you could decapsulate the chip and compare the silicon die, or check the errata behaviour (I can't imagine they re-implemented it themselves, up to the mistakes). The next step would be to have a CS32F103 chip in a package marked as STM32F103.

GC

Most ST-LINK minis which I get now use the CKS32 chip. I'm a bit sad because the CS32F103C8 really only has the advertised 64 KB of flash, while the STM32F103C8 actually has 128 KB (e.g. what the STM32F103CB has), and when you have a lot of debugging strings in your firmware, you very soon reach the limit of the 64 KB. Thus, on my quest to find ST-LINK minis with STM32F103 (e.g. where the ground pin is not between SWDIO and SWCLK) I landed on this one. Sadly it also does not use a STM32F103, but a STM32GC102C8. I have no idea what this chip is. The GC series does not exist (at least ST doesn't mention it anywhere), and it predates the new G series. I'm not sure if this was to save cost, because this is the first board I see with 2 ESD protections (one for USB, the other for SWDIO/SWCLK in addition to the inline protection resistors, and none for RST/SWIM).

Baite

dongle front dongle back board front board front

The Baite ST-Link V2 is my favorite clone since it supports JTAG, SWD, and SWIM (for STM8).

They seem to use the same board also for several other programmers, and since the pinout is not on the case I've decided to make my own sticker.

pinout sticker pinout

I've also reversed the board layout to get the schematic. The connector pins are all protected with 220 ohms resistors.

board front board front

There is a newer version marked as “V2A” (under the crystal), but the schematic is pretty much the same with the following changes:

  • all pads for the micro-controller are present (there is even solder mask between them)
  • they added a SWD port
  • the STM32F103C8 has been replaced with a STM32F101CB, but they are treating it as a STM32F103 (like the other cheap dongles)
  • the passives are smaller
  • the routing is horrible

Black Magic Probe

The Black Magic Probe (aka. BMP) is a quite nice SWJ adapter because it comes with an embedded GDB server. Thus no need to have an OpenOCD server to control the SWJ adapter. You can directly connect GDB to this adapter (over USB CDC ACM).
It also comes with a UART port (over a second USB CDC ACM). This is very useful while developing (for printf debugging).

The hardware comes with some disadvantages though:

  • the ARM Cortex SWJ connector uses a small header (not very dupont-wire friendly)
  • the separate UART is not always populated (UART is also available on the SWJ connector)
  • it is expensive (> $50), but this price is quite reasonable since it supports the project
  • it was sold out for quite some time, encouraging me to look for an alternative

Because the firmware is open source it is possible to port it to other hardware, and people already did it.
It has been ported on the blue pill, but I don't find this board as handy as a dongle.
It has also been ported to the ST-Link V2 clone, but then there is no additional UART anymore.

Altera USB-Blaster

device front

The USB-Blaster is from Altera. It is often used to flash FPGA, but is a general purpose JTAG adapter.

:!: be aware that here the VCC{TARGET} pin has to be connected to a reference voltage used for the JTAG communication, generally provided by the target device on the board (often 3.3V or 1.8V). Else the signals can not be detected by the JTAG adapter.

First add the rules for normal users to be able to access the device (udev rule based on the VID and PID shown by lsusb). This has only to be done once, before the device is plugged in to be used:

echo -n 'Altera USB-Blaster JTAG adatper' | sudo tee -a /etc/udev/rules.d/60-altera-usb-blaster.rules
echo -n 'ATTR{idVendor}=="09fb", ATTR{idProduct}=="6001", MODE="666"' | sudo tee -a /etc/udev/rules.d/60-altera-usb-blaster.rules
sudo udevadm control --reload-rules

To be able to use it I had to recompile OpenOCD for the USB-Blaster to use libftdi (maybe because it's a clone).

git clone http://git.code.sf.net/p/openocd/code openocd-code
cd openocd-code
./bootstrap
./configure --enable-usb_blaster_libftdi
make
sudo make install
cd ..

Else OpenOCD hangs, uses 100% CPU, and has to be killed using -KILL.

openocd --file interface/altera-usb-blaster.cfg
 
Open On-Chip Debugger 0.10.0-dev-00189-g554313b (2016-01-12-11:26)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Warn : Adapter driver 'usb_blaster' did not declare which transports it allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
none separate
cortex_m reset_config sysresetreq
Info : No lowlevel driver configured, will try them all
Info : Altera USB-Blaster II found (Firm. rev. = 6��)
Info : This adapter doesn't support configurable speed
openocd --debug 3 --file interface/altera-usb-blaster.cfg 
 
...
Debug: 385 845 tcl.c:497 handle_nand_init_command(): Initializing NAND devices...
Debug: 386 845 command.c:145 script_debug(): command - ocd_command ocd_command type ocd_pld init
Debug: 387 845 command.c:145 script_debug(): command - ocd_pld ocd_pld init
Debug: 389 846 pld.c:207 handle_pld_init_command(): Initializing PLDs...

Now you can also use it, here with an STM32F1 micro-controller:

openocd --file interface/altera-usb-blaster.cfg --file target/stm32f1x.cfg
 
Open On-Chip Debugger 0.10.0-dev-00189-g554313b (2016-01-12-16:26)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Warn : Adapter driver 'usb_blaster' did not declare which transports it allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
none separate
cortex_m reset_config sysresetreq
Info : No lowlevel driver configured, will try them all
Info : usb blaster interface using libftdi
Error: unable to get latency timer
Info : This adapter doesn't support configurable speed
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints

The original uses FTDI FT245 and MAX CPLD chips. There are numerous clone variants, with various quality and voltage support.

SiLabs USB-Blaster

This one uses a Silicon Labs C8051F321 micro-controller and a 74LVC125 quad buffer (for signal voltages from 1.65 to 3.6 V).

SiLabs USB-Blaster front SiLabs USB-Blaster back

PIC USB-Blaster

This one uses a Microchip PIC18F14 micro-controller (with embedded 3.3V LDO) and has no buffer (thus only supporting 3.3 V signals).

PIC USB-Blaster front PIC USB-Blaster back

ARMJISHU USB-Blaster

This one uses a ST STM32F101 (as a STM32F103 with USB support) micro-controller and a 74HC244 octal-buffer (for signal voltages from 2.0 to 6.0 V).

ARMJISHU USB-Blaster front ARMJISHU USB-Blaster back

I also reversed the schematic. It shows that the hardware can also drive the signals (at 3.3 V) in case Vcc_target is not connected, and you can add an uSD card slot or SPI flash. I don't know if these features are supported in software.

ARMJISHU board USB-Blaster front ARMJISHU board USB-Blaster back

The SEGGER J-Link supports JTAG, SWD, SWO, RTCK, and voltage reference (or provide 3.3V). That makes it one of the most complete JTAG adapter. The differences between the versions are documented here.

There are plenty of different J-Link v8 and v9 clones available, from light version with the minimum number of components, to full version with all features. But v8 and v9 are not supported anymore by J-Link, meaning no new feature will be added to them. Instead I recommend to get the J-Link EDU which is a supported v10 and not expensive.

Here pictures from devices not from official distributors, thus they might not be genuine but only clones.

They come in the same case:

device front device back

Here a J-Link v8 with large passives:

board front board back

Here a J-Link v8 with smaller and a bit less passives:

board front board back

Here a light J-Link v9. v9 uses a STM32F205 (providing 20 MHz JTAG/15 MHz SWD) while v8 uses a AT91SAM7S (providing 10 MHz JTAG/4 MHz SWD):

board front board back

Here a J-Link v10. It uses a NXP LPC4337 which supports USB high speed, and allows faster debugging speeds. In addition to the others, it adds cJTAG support:

board front board back

Here a J-Link OB. It is supposed to be embedded on development board and provide an easy way to flash the main micro-controller. It have much less capabilities (no JTAG, only SWD, …) and less protections, but is a lot smaller and sufficient for most tasks. Additionally it provides a UART interface, ideal for printf debugging. I actually can be implemented on several micro-controller, and in my case a STM32F072.

board front board back

Texas Instruments XDS100v3

The XDS100v3 supports cJTAG (aka. IEEE 1149.7, or SWD alternative), but I have not been able to successfully use it yet.

Note: this adapter uses the TI 20-pin (cTI) pinout.

device board front board back

DISTORTEC JTAG-lock-pick Tiny 2

The JTAG-lock-pick Tiny 2 is just a very fast (using a FT232H chip), and compact (although it could be even more compact if the component were on both sides) JTAG adapter supporting 1.4V to 3.6V signals (5.5V tolerant), multiple pinouts possible (using a CPLD), RTCK, SRST, and TRST.

board front board back

tricks

scan chain

JTAG devices are called Test Access Points (TAP). One micro-controller can have several TAPs, by chaining them. Devices with TAPs can also be chaining. But each TAP has an identity (IDCODE) and can be selected individually.

Thus it sometimes is useful to just list the TAPs available on a chain to know which devices are present.

This is easily done with urJTAG (here with the USB Blaster):

jtag 
 
UrJTAG 0.10 #2007
Copyright (C) 2002, 2003 ETC s.r.o.
Copyright (C) 2007, 2008, 2009 Kolja Waschk and the respective authors
 
UrJTAG is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
There is absolutely no warranty for UrJTAG.
 
warning: UrJTAG may damage your hardware!
Type "quit" to exit, "help" for help.
 
jtag> cable UsbBlaster
Connected to libftdi driver.
jtag> detect
IR length: 9
Chain length: 2
Device Id: 00111011101000000000010001110111 (0x3BA00477)
  Unknown manufacturer! (01000111011) (/usr/share/urjtag/MANUFACTURERS)
Device Id: 00010110010000010000000001000001 (0x16410041)
  Unknown manufacturer! (00000100000) (/usr/share/urjtag/MANUFACTURERS)

OpenOCD also scans the chain if no target is provided (the adapter still need to be defined):

openocd --file interface/altera-usb-blaster.cfg
 
Open On-Chip Debugger 0.10.0-dev-00189-g554313b (2016-01-12-16:26)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Warn : Adapter driver 'usb_blaster' did not declare which transports it allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
Info : No lowlevel driver configured, will try them all
Info : usb blaster interface using libftdi
Error: unable to get latency timer
Info : This adapter doesn't support configurable speed
Warn : There are no enabled taps.  AUTO PROBING MIGHT NOT WORK!!
Info : JTAG tap: auto0.tap tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: auto1.tap tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -irlen 4 -expected-id 0x3ba00477"
Warn : AUTO auto1.tap - use "jtag newtap auto1 tap -irlen 5 -expected-id 0x16410041"
Warn : gdb services need one or more targets defined

0x3ba00477 corresponds to the Cortex-M3 TAP, and 0x16410041 to the boundary scan TAP, as documented in the STM32F1xx reference manual.

While the ST-Link v2 is mainly meant to be used as SWD adapter, it also supports JTAG. Both are implemented with the High Level Adapter (HLA) driver. But it seems scan chain is not supported by the HLA.

openocd --file interface/stlink-v2.cfg -c "transport select hla_jtag" -c "adapter_khz 100"
 
Open On-Chip Debugger 0.10.0-dev-00189-g554313b (2016-01-12-16:26)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 100 kHz
Info : clock speed 100 kHz
Error: BUG: current_target out of bounds
jtag.txt · Last modified: 2024/01/07 17:49 by 127.0.0.1