Diving into JTAG — Usage Scenarios (Part 5)

In previous articles, we have considered the primary uses of JTAG, including debugging and testing boards in production. For firmware developers, the first - debugging - is the most common. In this article, I want to look at two uses of JTAG Boundary Scan, which are also common tasks for a firmware developer: board bring-up and reverse engineering.

Getting Started

To make working on this use case more convenient you need a specialized program. In this article, we will look at working with the program TopJTAG Probe and debugger SEGGER J-Link. These aren’t the only tools suitable for this task, but I am a long-time fan of J-Link debuggers, and the TopJTAG Probe program turned out to be the simplest and the most accessible from a quick Google search.

While many people are familiar with SEGGER products, TopJTAG Probe requires an introduction.

The TopJTAG Probe program is software that works with the JTAG interface and is used for testing printed circuit boards (PCB). This software is commonly used to diagnose and repair PCBs and work with microcontrollers and other devices that support JTAG.

A boundary-scan (JTAG) based simple logic analyzer and circuit debugging software. It provides the ability to monitor pin values in real-time without interference with the normal operation of a working device and to interactively set up pin values to test board-level interconnects or on-chip internal logic.

To start working with TopJTAG Probe, we need to create a new project. To do this, go to the File->New Project Wizard menu.

TOPJtag new project creation step 1

In the next window, select the required JTAG Probe and frequency. In my case, it is SEGGER J-Link and 12 MHz.

TOPJtag new project creation step 2

Click Next.

The program will scan our JTAG circuit and display a list of available TAP IDs.

You should already have a debugger connected to the board and the computer for this step to go well

TOPJtag new project creation step 3

Click Next.

At this point, you must specify .BSD files for each detected TAP. If you do not specify a .BSD file for a TAP, it will be put into the BYPASS state.

We specify STM32F405_415_407_417_LQFP100.bsd file for the first TAP - SGS/Thomson (06413041h) as it is responsible for Boundary Scan. We leave the second TAP in BYPASS. To select a file, click the CLICK HERE TO SET link and select the desired file.

TOPJtag new project creation step 4

After that, press Finish, and the program is ready.

Appearance of the program:

TOPJtag the main window

1 - Pins Window. The Pins window lists all pins belonging to the selected device. Any pin can be quickly located by typing its name, number, or port name into the search box. The pin or bus name, PIN, port name, type, and current value are displayed for every pin.

2 - JTAG Chain (Main) View. The JTAG Chain view (main program’s view) shows package outlines with color-coded pin values. These values are updated while the boundary scan is running.

Device instructions are displayed below the package outline.

Pin values are color-coded. Black means 0, red means 1, brown means high-Z, and blue means linkage pin. For bidirectional pins, it is possible to display either input or output values.

3 - Watch Window. The Watch window keeps pins of interest in one place to simplify monitoring and control.

4 - Waveform Window. The Waveform window records and displays waveforms. This is a wonderful tool to view and analyze a signal’s history. It is particularly useful for fast-changing signals.

Board Bring Up

Although assembled PCBs can be tested in production, as far as I know, it is not a mandatory procedure. So when these boards come to the Embedded department, especially when it’s the first batch that firmware/embedded developers will work with, the boards should be tested to ensure they work properly before they start working on the firmware. Usually (at least in the case where I worked), this is done by the circuit designer. Still, since the microcontroller is empty, this check is limited to the test that the board does not burn up when turned on and that the power supply system provides all the necessary voltages.

Sometimes, a special test firmware can be prepared specifically for bring-up, which automatically or via the CLI interface can enable/disable board modules for testing. In any case, no matter how it happens, bring-up almost always requires interaction between the embedded and circuit designer and additional work to create test firmware.

However, JTAG Boundary Scan can facilitate this work by allowing the circuit designer to control the microcontroller pins and thus perform a better and deeper analysis of the board without depending on the programmer. It also saves the programmer from having to write special firmware for bring-up. You only need a test board, a .BSDL file for the corresponding microcontroller, a debugger, and a unique program to control the controller pins through GUI. Also, an additional advantage of this approach is universality, i.e., you don’t need to write a new version of the test firmware for each new microcontroller. And if you remember that Boundary Scan allows you to check the signal integrity for a multiprocessor chain, where processors may have BGA cases and multilayer boards, and it may be very difficult to get to the contacts with probes.

Let’s see what is needed for an elementary bring-up. To begin with, at least, you need to be able to control the microcontroller pins (set to logic one/logic zero) and read the state in which the microcontroller pin is located, and JTAG allows you to do this, and programs like TopJTAG Probe allow you to do it more or less conveniently.

As a board for bring-up, I will use what I am already familiar with from the previous parts. STM32F407G-DISC1 with microcontroller STM32F407VG.

GPIO output control

Let’s control the LEDs on our board. Quite a workable task for bring-up. So we know that the LEDs are connected to pins: PD12, PD13, PD14, PD15. They are turned on by setting the pin to a logical one and turned off by a logic zero. To select the required level on a pin, it is necessary to find this pin in the Pin window and select the necessary actions from the context menu:

GPIO input state view

Another necessary operation for such a bring-up is to view the state of the chip pin. This can also be done using the JTAG Boundary Scan and TopJTAG application. You can view the output state either in the Watch window or in the Waveform window. Let’s look at the state of the output to which the button is connected:

Note: As mentioned in the article Diving into JTAG. Part 3 - Boundary Scan, there can be several scan cells per pin, and here you can see two of them: one for receiving and one for transmitting. When the controller transmits something, the receiving scan cell duplicates this signal, as seen in the video with LEDs. Still, if the output works only for receiving, the signal is present only on one cell, as seen in the video with the button.

Reverse Engineering

One of the exciting things is that the SAMPLE instruction does not affect the firmware in any way, which means that you can use it for a logic analyzer built into the controller. Where can it be useful? For example, when you don’t have an oscilloscope or analyzer. And, as it seems to me, this function can be useful when reverse engineering a board, especially microchips with BGA-type packages or multilayer boards when it is difficult to determine with a simple multimeter which pin of the chip is responsible for what and then using the SAMPLE command can help.

However, this is a very simple logic analyzer. While seeing some very simple and low-speed signals (such as controlling LEDs, pressing a button, or controlling some load) with this analyzer, it is quite easy and simple as shown in the chapter above, when dealing with higher-speed protocols, the signal that is drawn on the Waveform is very distorted. Here is an example of how the transmission of the symbol “U” (which has a code equal to 0x55) through UART at 1200 baud looks like:

TOPJtag uart 1200-baudrate-view

and at 2400 baud:

TOPJtag uart 2400-baudrate-view

As you can see, even at 2400 baud, the signal is distorted (2 bits were lost).

And here is what the SPI signal looks like with baudrate of 250 KBits/sec:

TOPJtag spi waveform

As you can see, it is hard to recognize SPI from this waveform, especially if you look at the SCK signal.

Most likely, the impossibility of analyzing higher-speed signals in this way is rooted in the limitations of the software and debugger that I use because they are not designed for such a task. There may be software and hardware for this purpose somewhere, but unfortunately, they are unavailable to me.

However, despite such limited use of this functionality, it can still be useful in some specific cases: you can see which pins of the controller are alive and functioning at all or analyze the logic of the firmware, for example on this example:

You can see that after we press the button, communication starts on some protocol. Although it is difficult to understand it from the signal, it is SPI protocol.


In this article, I have expanded on the area of JTAG usage. The examples may be rare in real life, but they may be useful for someone. I will now use the JTAG boundary scan for bring-up and board repair. :)

In the next article (most likely the final one), we will dive a bit into the security issue related to JTAG: we will consider ways to restrict access to the JTAG interface and also ways to bypass these restrictions.

Note: This article was originally published by Aliaksandr on his blog. You can find the original article here.

See anything you'd like to change? Submit a pull request or open an issue on our GitHub

Aliaksandr Kavalchuk is a firmware engineer with over 10 years of experience.