I was recently at a seminar for ARM MCUs and Freescale was talking about their new Kinetis devices (now I can even spell Kinetis). They talked about their "tower" eval boards using a USB connector for debug. Funny how the keep saying you can use a JTAG cable, but never actually said it uses a JTAG port! I'm not sure if there is any significance to that or not. It appears to use a standard JTAG port on a PC for the debug software interface.
However, that is pretty much the end of what they explain. They use a Freescale 8 bit MCU to implement a USB to JTAG convertion. The 8 bit MCU also connects a serial port to the Kinetis part and seems to provide some basic revision info on the board and manages power.
As far as I can tell, Freescale has plopped one of their own parts on the board with proprietary firmware as a JTAG interface and called it "Open Source JTAG". Does anyone know if this is really open source in any way? Or is Freescale just trying to give us a warm fuzzy feeling?
I tried to ask some questions about this at the seminar, but didn't get any real info out of them.
In a situation like this, I would think more about asking if it has a "Open Specification" instead of been "Open Source".
For a interface like this, my first question would be: Does Freescale _openly_ provide enough information for support for the Freescale supplied
8 bit MCU interface to be added to OpenOCD/gdb if anyone were inclined to do so ?
If they don't then the interface is not open in any way at all.
If they do, then the 8 bit interface device can at least be considered to at least have a open API-level interface specification.
The next level of questioning however would be about if Freescale provide enough information to allow you to build your own interface device to replace the Freescale supplied one on the board.
If they don't then it cannot be truly considered open at a open source type level.
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
I think they use an interface called "OSBDM" which is one of a whole family of similar open-source debugging interfaces originally developed for Freescale's 8- and 16-bit micros. The main source of information are the Freescale forums, but unfortunately they are a total unorganized mess.
The question there is "who" do you ask? the presenter at a multi- vendor presentation is not a wealth of knowledge. He tossed around the "Open Source" whatever name as if it was a Good Housekeeping seal of approval.
I'm pretty sure the extent of their involvement will be to point me to the various "open" whatever projects.
e
That much they do. From what I can gather the firmware is out there for all to see. You will have to use one of their chips to host it unless you want to do some porting, but that is not a big issue.
My bigger concern is about what software will talk to it. You mention GDB/OpenOCD. I know what a debugger is, which is what I assume GDB is about. But what does OpenOCD do? I don't get how that fits into the picture. Does it handle the translation between commands that GDB speaks (which I guess would be target and device independent) and the protocol that has to be used to talk to the JTAG adapter? If so, is there anything like a spec for either side of this interface?
Funny how so many open source projects are so bad at explaining what they are about. A lot of the cores on opencores literally give one sentence of description. The OpenOCD user guide intro says, "The Open On-Chip Debugger (OpenOCD) aims to provide debugging, in-system programming and boundary-scan testing for embedded target devices" and then dives into talking about the adapters. It doesn't talk any further about what OpenOCD does or what it connects to on the other side and none of the "how" for any of it.
Thanks for the link. I have found some info on OSBDM. From this page it appears that PEMicro is using this as a way to get you into their camp so they can sell you a bigger and better adapter... nothing wrong with that. I just want to understand the whole tool chain for debugging. I also would like to figure out what is useful across the spectrum of targets and how restricted any of these components are.
CodeWarrior and IAR should support OSBDM on ARM. I'm not aware of any open-source tools that would support this combination (IIRC there are some tools for Freescale's 8/16-bit micros). There's been some talk of support for the Kinetis chips on the OpenOCD mailing lists, but I don't think anything has been done yet, and I also don't know if this would include OSBDM support.
OpenOCD is a JTAG programmer and debugger 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.
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.
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.
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 memory.
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.
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Yes, On the host side it speaks the GDB remote debug protocol. Also there is a telnet command-line interface. Use of these is explained in the manual.
On the target side it speaks whatever is required to talk to the many compatible adapters. FTDI based ones especially plus other USB and parallel port types.
It was always clear to me, I think the openocd manual is very good actually.
Yes, it only makes sense that it would talk "whatever is required". This layer must correspond to the JTAG adapter to target protocol in some manner. It seems like everything has been done with little coordination and is a collection of "ad hoc" approaches. There must be some underlying commonality. I guess that is what you get when the goal of each vendor is to get you to use their approach end to end.
It may be clear to you, but to someone who isn't familiar with it an adequate basis is not provided. I think the example I gave is very illustrative. But that is not the point, or at least my point. I am trying to come up the learning curve. BTW, part of the problem is terminology. For example, Simon's reply talks about using an "ARM- JTAG cable" when it would be more clear if he said a JTAG adapter. He knew exactly what he meant, but I had to figure it out from context. Not a big thing, but there are lots of things like this. The terms JTAG and Debugger are used for everything so that it is hard to tell what is being discussed.
OpenOCD provides an interface for a user or a debugger like GB to connect to a JTAG adapter... or actually to the driver for the JTAG debugger. There are JTAG adapters that can be copied, like the wiggler, but they use (or did at one time) what is still a proprietary driver.
I'm also very unclear about the protocols for the various layers. JTAG specifies one or maybe two layers, the transport of commands across the interface and the commands for operating the TAP controller. I'm not sure, but I expect this is considered one layer. The JTAG adapter provides the electrical interface and for any devices more complex than the Wiggler, also provides the layer that transports the TAP commands. Outside of that I have little idea of what the protocols are and exactly where they are implemented.
I guess one thing I don't get is why OpenOCD is separate from GDB. How is GDB used without OpenOCD? What it the protocol between them? How does this protocol relate to the target? Is it at all target specific? Which of the layers are target specific?
All these years I have learned only enough about JTAG to get stuff to work. I think everyone is like this. As a result very few people really understand the design of the various tools for using JTAG debugging. Now I want to learn more so I can deal with debugging issues of adding new devices and new tools.
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 independent.
rd
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?
Perhaps that is part of what I need to learn more about.
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?
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 mystery!
I can understand your confusion. The reason I referred to a "ARM-JTAG cable" was because I was referring to a specific product:
formatting link
Be aware that if you look at some of the tutorials linked from that page, then there is some out of date material. For example, OpenOCD's scripting got a major reworking in a recent release, so some of the older OpenOCD scripts will not work as shown in the tutorials.
Don't forget that gdb is a general debugging tool and many (most?) people will only ever use it to debug code running in native mode on the same machine as gdb.
I use the same physical ddd frontend binary to debug both local and remote target code. The difference is that when I startup ddd to debug a remote target, I tell it to invoke a gdb which has been built as part of my cross compiler toolchain.
OpenOCD is only one of the possible remote target tools and gdb had remote target support before OpenOCD IIRC. gdb defines a generalised remote target communications protocol to be used between itself and a remote implementation (called the GDBserver) running over TCP/IP or a serial line.
When you are debugging, say, a program running under Linux on a embedded board, the GDBserver (which is supplied as part of the gdb kit) generally runs on the remote target itself.
OpenOCD is different because it emulates the GDBserver and runs on the same machine as the gdb client. We (the humans running gdb or a gdb frontend) know that OpenOCD is talking via JTAG to the target board, but gdb itself only sees a program emulating the GDBserver running over a TCP/IP connection.
As well as the generalised gdb commands, such as setting breakpoints, you can also issue OpenOCD specific commands from gdb with gdb's "monitor" command. For example, in one gdb startup script I have:
monitor reg pc 0x00000000
Everything after the "monitor" is a command to be passed as-is to the remote GDBserver (in this case OpenOCD emulating a GDBserver) and is not interpreted by the client gdb. In this case, the "reg pc" command is a OpenOCD specific command.
This "monitor" command is about the only thing in gdb which is target specific. Other gdb commands, such as setting a breakpoint, are mapped from the generalised gdb protocol into a OpenOCD specific sequence of JTAG commands by OpenOCD itself. (If my understanding is incomplete, I would appreciate been corrected).
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Yes, it is JTAG only and it is the only tool in the chain I mentioned which has specific JTAG knowledge.
Different programs with different goals designed by different groups.
OpenOCD is designed to do one thing only: interface to a board via a JTAG interface and implement traditional JTAG functionality.
gdb is to designed to run on a wide range of operating systems debugging both native code and code running on many different types of remote targets.
A new type of JTAG interface device will require code changes.
A new board with a different combination of OpenOCD supported devices can be handled (usually) through a configuration script.
Adding new functionality (say adding _direct_ support for writing to a SPI connected NOR flash) will require code changes. Please don't ask me how I know this to be the case for this specific example. :-)
Different types of devices may or may not require source code changes. For example, I am not fully clear what the situation is with NAND flash devices on a board.
Sorry. :-)
The JTAG adapter and driver are implemented within (and only within) OpenOCD.
gdb can issue human specified monitor commands which are OpenOCD specific, but OpenOCD converts general gdb commands to JTAG specific commands.
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
That statement (with it's implied lack of _direct_ JTAG support within gdb itself) is stronger than I can justify with my level of experience, so let me clarify: some parts of GDB may have direct support for specific JTAG devices (even though I have not yet come across this support if it exists), but when OpenOCD is been used to connect to a device, then all JTAG specific driver/adapter support which is actually used to talk to the device is within OpenOCD itself.
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Let me expand a little on that with some history of embedded gdb debugging before OpenOCD (and for non-ARM targets). You probably know much of this already, but perhaps by putting it in slightly different words it will help Rick (and maybe others) understand better. I hope I don't make /too/ many mistakes and confuse things further.
gdb is a program built with three "ends" - a front-end, a middle-end, and a back-end. The mainline version comes with several front-ends, several middle-ends, and several back-ends. There are also specific ports or patched versions with additional variants of these ends. On top of this, it can be compiled for different hosts (for example, running on Windows or Linux) and for different targets (x86, ARM, etc.).
This makes it a very flexible program. For some uses, it is self-sufficient. For other uses, it forms part of a chain of programs - which may even include more than gdb.
At the front-end, you have the connection from the higher level world to gdb. This can be using gdb's built-in command-line interpreter (for those that like a fast and efficient interface at the cost of a significant learning curve). There is also a graphics interface, Insight, that is often built into the gdb binary. Or it can also receive commands in a more concise format via a pipe, serial port or a tcp/ip socket - this is how other front-ends like ddd, Eclipse, CodeBlocks, etc., use gdb as their back-end debugger. The front-end, along with the protocols used, are largely independent of the target, the language, and the back-end (though when using the CLI there will be some specific commands).
The middle-end supports the language and the target architecture. gdb supports C, C++, Ada, and various other languages. And it supports a huge range of targets. It is the middle-end that handles loading files, understanding debug symbols, registers, reading and writing memory, etc.
The back-end also has a number of options. It can connect to a native process on suitable OS'es (such as for natively debugging programs running on Linux or Windows). It can also connect using a serial port, pipe, or a tcp/ip socket and communicate with a lower-level debugger using the gdb debugging protocol. This protocol is mostly, but not entirely, independent of the target architecture. It is also sometimes build with target simulator backends.
Mainline gdb by itself can therefore not debug embedded systems. It knows nothing about jtag, BDM, or any other way of connecting to an embedded system. The most common way to handle this is to have a proxy program that knows about the low-level interface, and which communicates with gdb over a tcp/ip socket.
It used to be common practice to make patched versions of gdb that directly support debugger interfaces. For example, I have a gdb build that communicate with a MC68332 using a parallel interface BDM debugger. Such patched monolithic builds made sense before, for speed reasons - now host systems are so fast that it makes more sense to use development-friendly modular arrangements with separate proxies.
Sometimes these proxies run directly on the target. This is often the case for debugging embedded Linux systems - here the "proxy" may in fact be a limited version of gdb running on the target. But mostly the proxies run on the host, and communicate with a debugging interface of some kind.
For example, with the CodeSourcery gcc toolchain for the ARM, you get some programs they call "debug sprites". These are specific to the particular debugger interface, and let you use the same gdb for any supported debugger. gdb talks to the sprite, and the sprite talks to the hardware (via USB, typically). The USB debugger interface then talks to the jtag interface on the target processor.
Sometimes these proxy programs are not open source. For example, TI has not released information about jtag debugging for the msp430. But it was willing to release it under an NDA to some msp-gcc developers. So they wrote the a proxy, released as binary only to protect the NDA information, allowing GPL'ed gdb to talk to the msp430 processors.
And sometimes the proxy is neither on the host or the target, but is on an "intelligent" debugger unit, such as the ZY1000 debugger which connects to the host by Ethernet. (The ZY1000 runs OpenOCD.).
So where does OpenOCD fit into this picture? OpenOCD is a debugger proxy program (it does other things as well). It is designed to be very flexible - it supports a wide range of debugger interfaces, scripting, almost all types of ARM (and a few other targets such as some MIPS devices), flash programming, board support, etc. The idea is to have one common proxy program that suits most uses - at least in the ARM world - rather than having lots of different proxy programs.
OpenOCD therefore "knows" about JTAG and a range of debugger interfaces. Many of these interfaces are very simple - it is common to use the FTDI2232 chips for JTAG interfaces, which blindly pass data between the USB and the JTAG connection. Others are more complex and have more advanced protocols.
As well as acting as a gdb proxy, OpenOCD supports scripting and an interface designed to control programming flash or other setup on devices, or to handle other jtag tasks such as board testing.
The OSBDM devices apparently use the same protocol as P&E Micro debugger cables. As far as I could see, OpenOCD doesn't support that (as yet).
CodeSourcery's gcc toolchain /does/ support Kinetis and OSBDM debugging using debug sprites. These are not open source, and only come with the paid-for versions of the toolchain, but the toolchain itself (including gdb) is still open source, and not particularly expensive (for the cheapest versions).
Is this protocol open? If I understand correctly, the OSJTAG(OSBDM) adapter source code is open source although I have not verified what license it uses. I guess a driver for the USB interface for this protocol would be needed? Any idea exactly what that would do? I guess it deals with the details of sending and receiving the commands from the USB interface. Then an OSJTAG interface is needed for OpenOCD. That would complete the chain for open source tools, yes?
So where do sprites connect into the chain as outlined by Simon? Do they connect to OpenOCD or directly to GDB?
David, thank you for an excellent explanation. This makes it all much more clear now. It would seem to me that if the source code for the JTAG adapter on the Freescale eval boards (OSJTAG) is available as open source, then the interfaces on either side would need to be open even if not documented. So it should not be a large job to make any of the open source tools compatible with it.
So I guess the only thing I am still not clear on is exactly what the protocol levels are on the target side. It seems clear that there is a protocol between GDB and OpenOCD. There are many protocols between OpenOCD and the various JTAG adapters. But a given adapter can work with multiple targets. At the JTAG point it is just a way to get commands into the target. What level of this hierarchy has to understand the debugging protocol of the target? I guess it would be OpenOCD, yes? Where is this documented? In particular, for the Kinetis devices could that be figured out from the OSJTAG code? Or does that just dumbly handle JTAG commands like the FTDI device? If not there, where would this info be available from?
Maybe I should say that I am trying to figure out how someone might add debugging support to a tool. I think OpenOCD would be used, so I guess we just need to make OSJTAG work with OpenOCD which would be a win/win.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.