Re: OpenOCD, was: Re: Freescale's Idea of Open Source JTAG

On Mar 19, 2:49 pm, Simon Clubley <clubley@xxxxxxxxxxxxxxxxxxxxxxxxxxx
Earth.UFP> wrote:

OpenOCD is a JTAG programmer and debugger interface.

Is it somehow unique to JTAG? Does it actually know anything about
JTAG or is it just a tool for controlling debugging interfaces in
general? I guess I expected this level of tool to be interface

It can be used as a standalone program (by means of a builtin scripting
language) from the command line to load code into a target board's
SRAM/RAM/Flash memory.

It can also be used in a server mode which allows gdb to connect to it
via gdb's remote target protocol. You can then use gdb to talk to the board
via the OpenOCD controlled JTAG interface.

I guess I am surprised that GDB doesn't include this capability. Were
they both developed together splitting the functionality for some
reason? Or did one exist before the other, with some capability on
its own?

OpenOCD has knowledge of a range of JTAG devices and various boards.
The builtin scripting language also serves as a configuration language
which allows developers to define new targets which OpenOCD does not
already know about.

Perhaps that is part of what I need to learn more about.

Developers wishing to add a new type of JTAG interface can modify the
OpenOCD source code to provide that support and then expose that new
interface via the scripting language.

Certainly scripting would be preferred over writing code for the guts
of a tool. Any idea of what things can be done in the scripting vs.
requiring code changes?

You ask how it all connects together. One example:

The physical setup for a board in front of me has a ARM-JTAG cable from
Olimex plugged into the JTAG connecter on the board and the other end of
the cable plugged into a (real) parallel port.

I run OpenOCD by giving it the name of one of my own scripts. The first
thing that script does is to load a OpenOCD supplied script which
defines the parallel port interface. It also loads a second script
which defines the attributes of the board attached to the JTAG device.

My own scripts, depending on requirements, can tell OpenOCD to go into
a server mode so that GDB can attach to it via gdb's target command, or
it can tell OpenOCD to load a program binary into the target board's

Therefore if I am running a debugger (I use the ddd frontend to gdb),
the comms path looks like this:

        ddd -> gdb -> OpenOCD -> target board.

ddd to gdb communications are via GDB's machine interface.
gdb to OpenOCD communications are via a TCP/IP port opened up by OpenOCD.
OpenOCD to target board communications are via the JTAG cable.

Thanks. I'm not looking for JTAG debugging 101. I have used JTAG
tools since they were invented. But I have always seen them as
proprietary devices end to end. The above signal flow is missing both
the JTAG adapter and its driver. Each of these things implement some
level of protocol. That is what I would like to learn more about. I
suppose by the time you get to ddd the protocol is the human
interface. But this still ties into the target in some way. At least
the three pieces of software you show are all open source. I get the
impression that Freescale's idea of open source debugging is to
publish the source for the MCU based JTAG adapter chip. The rest is