Using a JTAGulator

Author: HollyGraceful    Published: 06 August 2021    Last Updated: 03 July 2023

What is JTAG?

JTAG is short for Joint Test Action Group and generally refers to on-chip debugging interfaces that follow the IEEE 1149.x standard. The standard doesn’t mandate a certain connection – it just dictates a standard for communicating with chips in a device. It uses 5 pins: TCK, TMS, TDI, TDO and (options) TRST; which are (Test) Clock, Mode Select, Data In, Data Out, and Reset.

It can be useful to hardware hackers in various ways, such as extracting device IDs, extracting firmware, overwriting memory.

The trick however is finding a JTAG connector! There are several tools that can assist with that, such as JTAGEnum which can run on an Arduino (or Raspberry Pi), or the JTAGulator which is a dedicated device for finding JTAG.

Using the JTAGulator

The JTAGulator is a great little device, whilst albeit is likely much more expensive that using an Arduino for these tasks, it is an efficient tool. Sometimes finding JTAG can be tricky, if there are no obvious exposed pins it might require looking up chip datasheets to find the relevant pins. However, sometimes vendors give you neat little clusters of pins on-board which could be JTAG – as seen below:

Here you can see, on the lower right hand side of the board there are four collection of pins exposed, which are by default not populated. (Here of course I’ve added some wires to make accessing them simpler now that I know they’re JTAG and UART, but here are the steps I took to discover that)

In these cases you have a collection of pins which are interesting and potentially JTAG, you can connect up to 24 pins at a time to a JTAGulator and ask it to enumerate (by scanning through each possible pin-out permutation) if it can find a JTAG interface.

Before you connect the JTAGulator to the pins to test though, you’ll need to find a suitable ground point on the device – this is for a shared reference for the devices and is usually simple to do if you have a multi-meter to hand.

There are three common ways to find a ground point – the first is pins labelled on the datasheet as ground (or more commonly “GRD”), secondly is on exposed metal parts of the devices casing, thirdly is the ground pin of the power connector (where the power lead joins the board).

As I’ll be using test-clips I prefer to connect to a pin on the board, as opposed to the thick casing which might cause the test-clip to pop off whilst in use. So here you can see I have set my multi-meter to continuity test and I’m touching each probe between the metal casing (or you could use the ground pin of the power connector) and a pin I would like to test.

The multi-meter display will show 1 when disconnected and when connected to a ground point it should fall to almost zero – seen here at 0.01. Therefore the pin the red probe is touching is a GRD pin.

At this stage I’ll want to connect the GRD pin to the GRD pin of the JTAGulator (so they have a shared reference), then connect each pin I would like to test for JTAG to the “channels” on the JTAGulator – labelled CH0, CH1, CH2, etc. The ordering doesn’t matter for the channels as the JTAGulator will determine them automatically by trying each possible permutation.

I can connect to the JTAGulator using a terminal emulator – I use PuTTY on Windows and screen on Linux. The following screenshot shows my putty configuration:

I have selected COM4 as that is where my JTAgulator is – if you’re unsure, then check you Device Manager for which COM port number to use. On Linux this would generally be /dev/ttyUSB0. The speed (baud) will be 115200. Once you’ve connected you’ll get a readout like this:

If you power up your JTAGulator before you’re ready to connect to it, it will have already sent the ASCII art over the serial (USB) connector. If you would like to see it and were a little too slow – just hit the reset button on the JTAGulator after you’re all connected :)

As it says you can hit ‘H’ followed by enter for help (it’s not case sensitive by the way). In the help menu you’ll see two options for finding JTAG, referred to as “IDCODE” scan and “BYPASS” scan – the difference being that IDCODE will be faster but not find the TDI pin, whereas BYPASS will but will take a whilst longer.

Before you can do either, you’ll need to find the target voltage. Again the datasheet for the chip should tell you what this is – but Joe Grand the maker of the JTAGulator gave a faster method in his tutorial video; using a multi-meter and finding the power rail. He suggests setting a multi-meter to GRD and each pin-to-be-tested in turn and looking for a pin that gives an almost static readout. That would look something like this:

So I’ll set my JTAGulator to 3.3 by selecting ‘V’ and then typing ‘3.3’. If you forget this step the JTAGulator will politely remind you to set a target voltage :)

Once you’ve done that you can find JTAG with the type options mentioned above. I’ll use BYPASS here, as we’re in no rush and it’ll give all pins required. If you’ve set the target voltage it’ll ask for how many channels you have in use. I’ve hooked up my JTAgulator like this:

Now that we’ve connected out channels, set our target voltage, we can use IDCODE or BYPASS scanning – this screenshot shows the steps of running a BYPASS scan. It only requires the number of channels setting and since we’ve got CH0 to CH7 populated that’s 8 channels. Hit spacebar and wait about one minute:

Here the JTAGulator has given us what it believes is the correct pinout and also “Number of devices detected”. This number refers to JTAG-chains, which put simply is where multiple chips JTAG interface are connected together to allow for one JTAG connection to interact with multiple devices. In this example there’s only a single device in the “chain” and so, it reads 1.

At this point also grab the Device ID which will come in handy for using OpenOCD in a moment – you can do that with the ‘D’ command, and the JTAgulator will ask for the pin layout that it just gave you.

Here you can see it has read out 0x0000100F as the example devices ID.

 

Using the UM232H and OpenOCD

Now that we’ve found a suitable JTAG interface we can connect to it with a device such as a UM232H. There are several alternative chips that can interact with JTAG too, like the BusPirate. My UM232H looks like this up close:

I’ve included this image to save you ruining your eyes trying to read the pin labels which we’ll need in a second – alternatively get yourself a cute little magnifying glass before you regret it! I’d recommend a “Helping Hand” which includes a magnifying glass as well as two clips for holding boards/wires whilst soldering. Here’s what I use:

You’ll need to grab a copy of OpenOCD to drive the JTAG chip; I generally do this with Linux but it’ll run on Windows with a little work too. The pin-out for the UM232H is included within OpenOCD’s configuration files. If you’re on Fedora installation is as easy as:

sudo dnf install openocd

Then you can read the configuration file here:

The pins we’re interested are:

(Don't forget the GRD pin)
TCK ->  AD0
TDI -> AD1
TDO -> AD2
TMS -> AD3
TRST -> AC0

Which will result in something like this! (The connection at the top, the yellow and green wires, is setting the chip to take power over USB as opposed to taking power from the target board; if you’re struggling to get yours to turn on then you’re probably missing that connection :) )

At this stage we’ve connected the UM232H to the example board, powered board boards up, and connected to the laptop. You’ll now want to make an OpenOCD config file containing the Vendor ID we collected earlier. Save the following to a file somewhere sensible, I’ve just placed mine in my home folder called “config.cfg”. Remember to replace the red text with the Vendor ID you got from the JTAGulator earlier.

jtag newtap foobar tap -irlen 8 -expected-id 0x0000100F
adapter_khz 1000
transport select jtag

Now you can run OpenOCD with the following (remember to change the second config file to wherever you placed the above config file):

openocd -f /usr/share/openocd/scripts/interface/ftdi/um232h.cfg -f /home/hollyw/config2.cfg

Now we can connect to OpenOCD and communicate to the target chip’s JTAG interface! For example, you could run the following to test the connection is good:

telnet 127.0.0.1 4444
scan_chain

You’ve successfully discovered a JTAG interface, connected to it with OpenOCD and confirmed the connection is working as expected :)

 

That’s it!