Diving into JTAG. Part 5 — Usage Scenarios
Diving into JTAG protocol. Part 1 — Overview.
Diving into JTAG protocol. Part 2 — Debugging.
Diving into JTAG protocol. Part 3 — Boundary Scan.
Diving into JTAG protocol. Part 4 — BSDL
The main examples of JTAG usage, such as debugging and testing of boards in production, we have considered in the previous parts. And for firmware/embedded developers, only the first example — debugging — is the most useful. As far as I know, we almost never encounter the second option, although it can be very useful too. In this article, I want to look at two examples of JTAG Boundary Scan which I think can be very useful in the everyday work of a firmware/embedded developer: Bring-up and Revers Engineering.
Getting Started
For convenient work, you need special software and a debugger. In this article, I will consider working with the program TopJTAG Probe, and debugger SEGGER J-Link, but it doesn’t mean that only they are suitable for such tasks, just at the moment of writing this article I have them because I am a long-time fan of J-Link debuggers, and TopJTAG Probe program turned out to be the simplest and the most accessible at a quick googling.
While I think many people are familiar with SEGGER products, TopJTAG Probe requires a small description.
TopJTAG Probe program is software for working with the JTAG interface used for testing printed circuit boards (PCBs). This software is commonly used for diagnostics and repair of PCBs, as well as for working with microcontrollers and other devices that support JTAG.
A boundary-scan (JTAG) based simple logic analyzer and circuit debugging software. 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 for testing of 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.
In the next window select the required JTAG Probe and frequency. In my case, it is SEGGER J-Link and 12 MHz.
Click Next.
The program will scan our JTAG circuit and display a list of available TAP IDs.
Click Next.
At this point, you must specify the .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 on the CLICK HERE TO SET link and select the desired file.
After that we press Finish and now the program is ready to work.
Appearance of the program:
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 number, port name, type, and current value are displayed for every pin.
2 - JTAG Chain (Main) View. The JTAG Chain view (the main program's view) shows package outlines with color-coded pin values. These values are updated while the boundary scan is running.
A device instruction is displayed below the package outline.
Pin values are color-coded. Black means 0, red — 1, brown — high-Z, and blue — 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/or 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, in general 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 are going to work with, the boards should be tested to make sure they work properly before they start working on the firmware. Usually (at least that was the case where I worked) this is done by the circuit designer, but 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.
In some cases, a special test firmware can be prepared specifically for Bring-Up, which either automatically or via CLI interface can enable/disable board modules for testing. In any case, no matter how it happens Bring-Up almost always requires interaction between embedded and circuit designer and additional work to create test firmware.
However, it seems to me that 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 and not depend on the programmer. And it saves the programmer from having to write special firmware for Bring-Up. All you need for this is a test board, a .BSDL file for the corresponding microcontroller, a debugger, and a special program that allows you to control the controller pins through GUI. Also, an additional advantage of this approach as I see it 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 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.
So 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 already familiar from the previous parts STM32F407G-DISC1 with microcontroller STM32F407VG.
GPIO output control
Let’s try to control the LEDs on our board. Quite a workable task for Bring-Up, I think. So we know that the LEDs are connected to pins: PD12, PD13, PD14, PD15. They are turned on by setting the pin to a logic one, and turned off by a logic zero, respectively. 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 that is required 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:
Reverse Engineering
One of the interesting things is that the SAMPLE instruction does not affect the firmware in any way, which means that you can use it for a kind of logic analyzer actually built into the controller. Where can it be useful? For example, when you don't have an oscilloscope or analyzer at hand. And, as it seems to me, this function can be useful when Revers 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 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:
and at 2400 baud:
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 a baud rate of 250 KBits/sec:
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 simply not designed for such a task. And maybe there are software and hardware for this purpose somewhere, but unfortunately, they are not available 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 in this example:
You can see that after we press the button — communication starts on some protocol and although it is difficult to understand it from the signal, it is SPI protocol.
Conclusion
In this article, I have tried to expand the area of JTAG usage a little bit. The examples may be rare in real life, but they may be useful for someone. At least for Bring-up, I will use JTAG Boundary Scan now. :)
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.
Next part: Diving into JTAG. Part 6 — Security
