The Many Faces Of JTAG

December 15, 2016 by Elliot Williams 48 Comments

Wouldn’t it be great if there were just one standard for attaching to, programming, and debugging hardware? If you could just plug in and everything would just work? Dream on, dreamer! But of course we hobbyists aren’t the only people to suffer from multiple standards. Industry has the same problems, writ large. In response to the proliferation of smart devices — microcontrollers, sensors, and their friends — on any given PCB makes it difficult to test them all, much less their function as a system.

The Joint Test Action Group (JTAG) got together in the mid-80s to make automated testing of circuit boards a standardized process. A JTAG port can be found on almost any piece of consumer electronics with enough brains to warrant it, and it’s also a tremendously useful entry point for debugging your own work and hacking into other’s. You’re going to need to use JTAG someday.

Implemented right, it’s a very cool system that lets you test any compliant IC on the board all from a single connector. It’s mostly used by hackers for its ability to run and halt individual processors, and put them in debugging modes, inspecting their memory states, etc. Essentially every microcontroller responds to JTAG commands, and it’s an incredibly widespread and powerful standard. A victory for rationality and standardization!

The connector pinout was, of course, left up to the manufacturer. The horror!

Five Signals

In principle, JTAG uses five signal lines. They form a chain starting at the debugger, where one device’s output is the next device’s input, until the result is returned back to the debugger.

654px-jtag_chain — JTAG, as imagined by Vindicator CC BY 2.5

Test Data In (TDI) is the input from the debugger
Test Data Out (TDO) is the return end of the chain
Test Clock (TCK) clocks this data along synchronously, similarly to SPI
Test Mode Select (TMS) lets the devices know that they’re being debugged — it’s a global chip select
Test Reset (TRST) is an optional signal that resets all devices in the chain

Continue reading “The Many Faces Of JTAG” →

Black Magic Probe: The Best ARM JTAG Debugger?

December 2, 2016 by Elliot Williams 48 Comments

We don’t always JTAG, but when we do, we use a Black Magic Probe. It’s a completely open ARM-chip debugging powerhouse. If you program the small ARM chips and you don’t have a BMP, you need a BMP. Right now, one of the main producers of these little gems is running a Kickstarter where you can get your hands on a nicely made one and/or a 1Bitsy STM32F415-based development board.

Why is the BMP so great? First off, it’s got a JTAG and a UART serial port in one device. You can flash the target, run your code, use the serial port for printf debugging like you know you want to, and then fall back on full-fledged JTAG-plus-GDB when you need to, all in one dongle. It’s just very convenient.

But the BMP’s killer feature is that it runs a GDB server on the probe. It opens up a virtual serial port that you can connect to directly through GDB on your host computer. No need to hassle around with OpenOCD configurations, or to open up a second window to run [texane]’s marvelous st-util. Just run GDB, target extended-remote /dev/ttyACM0 and you’re debugging. As the links above demonstrate, there are many hardware/software pairs that’ll get you up and debugging. But by combining the debug server with the JTAG hardware, the BMP is by far the slickest.

Full disclosure: we use a BMP that we built ourselves, which is to say that we compiled and flashed the firmware into a $4 STLink clone programmer that we had on hand. Breaking the required signals out required a bit of ugly, fiddly soldering, but we enjoy that sort of thing. If you don’t, the early-bird Kickstarter (with cables) looks like a good deal to us.

Mike Szczys Ends 8-Bit Vs 32-Bit Holy War!

May 11, 2016 by Elliot Williams 102 Comments

If you’ve read through the comments on Hackaday, you’ve doubtless felt the fires of one of our classic flame-wars. Any project done with a 32-bit chip could have been done on something smaller and cheaper, if only the developer weren’t so lazy. And any project that’s squeezes the last cycles of performance out of an 8-bit processor could have been done faster and more appropriately with a 32-bit chip.

Of course, the reality for any given project is between these two comic-book extremes. There’s a range of capabilities in both camps. (And of course, there are 16-bit chips…) The 32-bit chips tend to have richer peripherals and run at higher speeds — anything you can do with an 8-bitter can be done with its fancier cousin. Conversely, comparatively few microcontroller applications outgrow even the cheapest 8-bitters out there. So, which to choose, and when?

Eight Bits are Great Bits

The case that [Mike] makes for an 8-bit microcontroller is that it’s masterable because it’s a limited playground. It’s a lot easier to get through the whole toolchain because it’s a lot shorter. In terms of debugging, there’s (often) a lot less that can go wrong, letting you learn the easy debugging lessons first before moving on to the truly devilish. You can understand the hardware peripherals because they’re limited.

And then there’s the datasheets. The datasheet for a chip like the Atmel ATMega168 is not something you’d want to print out, at around 660 pages long. But it’s complete. [Mike] contrasts with the STM32F405 which has a datasheet that’s only 200 pages long, but that’s just going over the functions in principle. To actually get down to the registers, you need to look at the programming manual, which is 1,731 pages long. (And that doesn’t even cover the various support libraries that you might want to use, which add even more to the documentation burden.) The point is, simpler is simpler. And if you’re getting started, simpler is better.

Continue reading “Mike Szczys Ends 8-Bit Vs 32-Bit Holy War!” →

Local Hacker Discovers Card Edge Connectors

February 8, 2016 by Brian Benchoff 56 Comments

When [turingbirds] was looking around for the absolute minimum connector for a JTAG adapter, he wanted something small, that didn’t require expensive adapters, and that could easily and reliably connect a few JTAG pins to a programmer. This, unsurprisingly, is a problem that’s been solved many times over, but that doesn’t mean there isn’t room for improvement. [turingbirds] found his better solution by looking at some old card edge connectors.

Instead of 0.1″ pitch pin headers, weirder and more expensive connectors, the Tag Connect, or even pogo pins, [turingbirds] came up with a JTAG adapter that required no additional parts, had a small footprint, and could be constructed out of trash usually found behind any busy hackerspace or garage. The connector is based on the venerable PCI connector, chopped up with a Dremel and soldered to a JTAG or ISP programmer.

This is simply a card edge connector, something the younglings seem to have forgotten. Back in the day, card edge connectors were a great way to connect peripherals, ports, and anything else to the outside world. They were keyed, and you could only put them in one way. They were relatively cheap, and with a big coil of ribbon cable, you could make custom adapters easily. For low-speed connections that will only be used a few times, it’s very hard to beat a card edge connector.

Of course the connector itself is only half of the actual build. To turn a chopped up PCI connector into a JTAG adapter, [turingbirds] made footprint and part files for his favorite PCB design tool. In this case it’s Eagle, and the libraries that will plop one of these connectors down are available on GitHub.

Is this the latest and greatest way to plug a programmer into a board? No, because this has been around for 30 or 40 years. It does, however, put a programming port on a PCB with zero dollars in components, a minimum of board footprint, and uses parts that can be salvaged from any pile of old computers.

An MSP430 Flash Emulation Tool From An MSP430

October 6, 2014 by Brian Benchoff 44 Comments

It isn’t much trouble programming one of TI’s MSP430 chips, but outside of the official Flash Emulation Tool, TI doesn’t make programming one of these microcontrollers cheap. The most common way of programming an MSP430 is using a Launchpad Dev board, and [Vicente] has the best looking one yet.

The MSP430 series of chips can be programmed through JTAG or Spy-By-Wire, and the official, professional engineering tool from TI for these chips costs about $100. Those of us with more sense than money have another option – use one of the TI Launchpad dev boards as an MSP430 programmer.

[Vicente]’s project uses the MSP430G2 Launchpad, with just a few wires going to the proper connector found in the official programmer from TI. There are a few limitations; the programmer only works at 3.6V, so programming 1.8V devices might not be a good idea. Also, it only works with Spy-By-Wire and no JTAG support is available. Still, it’s a great looking project, and does exactly what it’s designed to.

Stepping Through Code On A Pace 4000 Set Top Box

September 19, 2014 by Mike Szczys 14 Comments

[Lee] wrote in to tell us about a Set Top Box he hacked. Before the cable industry lawyers get out their flaming swords… he’s not stealing cable, or really doing much of anything. This is a hack just for the adventure and thrill of making someone else’s hardware design do your bidding without any kind of instructions.

He posted about the adventure in two parts. The first is finding the JTAG header and identifying the pins. Arduino to the rescue! No really, and this is the type of Arduino use we love. Using a package called JTAGenum the board becomes a quick tool for probing and identifying JTAG connections.

The image above shows a different piece of hardware. From looking at it we’re pretty sure this is a Bus Blaster which is specifically designed for JTAG debugging with ARM processors. This is the beginning of the second part of his documentation which involves code dumping and stepping through lines code (or instructions) using OpenOCD and GDB. It’s a chore to follow all that [Lee] discovered just to write his name to the display of the box. But we certainly found it interesting. The display has a convoluted addressing scheme. We assume that there are cascading shift registers driving the segments and that’s why it behaves the way it does. Take a look for yourself and let us know what you think in the comments.

Unbricking A Router With A Raspi

November 15, 2013 by Brian Benchoff 18 Comments

About a decade ago, [Mansour] learned of the Linksys WRT54G, a wireless router that’s been shoved into just about every project under the sun. After learning of this device’s power, he decided a firmware upgrade was in order. Unfortunately, he accidentally bricked this router and left it sitting on a shelf for a few years.

Idle devices are the devil’s playthings, and when [Mansour] discovered a Samsung hard drive with a an SDRAM that was compatible with the WRT54G, he decided he would have a go at repairing this ancient router. There was only one problem: the most popular utility for programming the router through the JTAG header required a PC parallel port.

No problem, then, as [Mansour] had a Raspberry Pi on hand. The parallel port utility bit-banged the new firmware over to the router, something the GPIO port on the Pi could do in spades. By adding Pi support to the debricking utility, [Mansour] had a functional WRT54G with just a little bit of patience and a few wires connecting the GPIO and JTAG header.