In my last entry, I mentioned how a former boss decided that it would save the company big bucks if we just required people not to make bugs in hardware and software. While it is hard to argue against that point, it is equally hard to figure out how you'd actually make that happen.

When I'm selecting tools to work with, having a debugger is a pretty important part of the package. The ARM setup I've been building the last few weeks is no exception. I connected an Olimex JTAG adapter to the board. It is a shame, but the board doesn't have a dedicated JTAG adapter. A few solderless breadboard connections made short work of it, though.

The Olimex device has a standard JTAG DIP footprint and one side of it (the side furthest from the adapter's body; even number pins) is ground and supply voltage (on pin 2). I left pin 2 empty and just grounded one of the other pins. On the other side, I connected the wires like this:

That's it for the hardware. The JTAG interface plugs into a USB port.

The software to run the JTAG interface is OpenOCD. The listings from last week contain .openocd.cfg that tells the software how to find the JTAG interface and the details about the processor. At the start of that file are two lines that control how the server will talk to the rest of the world:

telnet_port 4444
gdb_port 3333

You can directly telnet into the JTAG server and do certain things, but that is largely unsatisfying. The real thing of interest is that you can set it to be a gdb remote host using the port indicated (3333, in this case). You simply start the debugger on your elf file and then issue commands like this:

target remote :3333
cont

This, of course, leaves you at the mildly uninteresting gdb command prompt. I am typically not a big fan of GUIs, but debugging is one of those things where a nice interface makes sense. If you build your own toolchain, you can get Insight — the GUI-based GDB — to work. I always seem to have some version mismatches with Tk though and so my experience has been spotty. There are, however, a few other ways you can approach your debugging.

For one thing, gdb supports a -tui flag that give you an old-style "curses" interface. The downside is it is text-based, but the upside is it is functional and runs fast even on a slow old system or bad network connection.

Since I am not particularly GUI-happy, that actually suits me fine. But I know many people will turn their noses up at it since it isn't a pretty resizable window. That's OK. There are a few options there, too. Of course, if you use Eclipse, it integrates nicely with gdb. You can also use ddd, which is a nice graphical tool that can show your data in interesting ways.

The only issue is that ddd expects to use the system default copy of gdb. Luckily, it lets you override that on the command line:

ddd –debugger arm-none-eabi-gdb

After that, it is simple to use the regular gdb command to connect to the OpenOCD server since ddd provides a console for entering gdb commands. I haven't tried it, but kdbg lets you specify the path to the copy of gdb it uses in its settings, so that should work as well.

Over the last few weeks, I've built up a development system for the ST ARM processor. The ETT ST-ARM Stamp and the Olimex JTAG adapter cost well under $100. I picked up free software tools. I wound up with pretty much everything you need to do C development on a powerful 32-bit processor that would have seemed like a supercomputer back when Dr. Dobb's first started. This is a good time to be an embedded systems developer!