Forums

Freescale's Idea of Open Source JTAG

Started by rickman March 19, 2011
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.

Rick
On 2011-03-19, rickman <gnuarm@gmail.com> wrote:
> 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? >
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
rickman <gnuarm@gmail.com> wrote:
> 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 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. -a
Anders.Montonen@kapsi.spam.stop.fi.invalid wrote:
> rickman <gnuarm@gmail.com> wrote: >> 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?
Looks like what you want: <http://www.pemicro.com/osbdm/index.cfm> -a
On Mar 19, 12:52=A0pm, Simon Clubley <clubley@remove_me.eisner.decus.org-
Earth.UFP> wrote:
> On 2011-03-19, rickman <gnu...@gmail.com> wrote: > > > > > I was recently at a seminar for ARM MCUs and Freescale was talking > > about their new Kinetis devices (now I can even spell Kinetis). =A0They > > talked about their "tower" eval boards using a USB connector for > > debug. =A0Funny how the keep saying you can use a JTAG cable, but never > > actually said it uses a JTAG port! =A0I'm not sure if there is any > > significance to that or not. =A0It 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. =A0They use =
a
> > Freescale 8 bit MCU to implement a USB to JTAG convertion. =A0The 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". =A0Does anyone know if this is really open source i=
n
> > any way? =A0Or is Freescale just trying to give us a warm fuzzy > > feeling? > > 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 supplie=
d
> 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.
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.
> 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 devic=
e
> 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.
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. Rick
On Mar 19, 1:37=A0pm, Anders.Monto...@kapsi.spam.stop.fi.invalid wrote:
> Anders.Monto...@kapsi.spam.stop.fi.invalid wrote: > > rickman <gnu...@gmail.com> wrote: > >> 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". =A0Does anyone know if this is really open source =
in
> >> any way? =A0Or is Freescale just trying to give us a warm fuzzy > >> feeling? > > Looks like what you want: <http://www.pemicro.com/osbdm/index.cfm> > > -a
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. Rick
rickman <gnuarm@gmail.com> wrote:
> 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. -a
On 2011-03-19, rickman <gnuarm@gmail.com> wrote:
> On Mar 19, 12:52&#2013266080;pm, Simon Clubley <clubley@remove_me.eisner.decus.org- > Earth.UFP> wrote: >> 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. > > 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? >
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
rickman <gnuarm@gmail.com> writes:

> On Mar 19, 12:52&nbsp;pm, Simon Clubley <clubley@remove_me.eisner.decus.org-
[...]
> > 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?
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.
> 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.
It was always clear to me, I think the openocd manual is very good actually. -- John Devereux
On Mar 19, 2:58 pm, John Devereux <j...@devereux.me.uk> wrote:
> rickman <gnu...@gmail.com> writes: > > On Mar 19, 12:52 pm, Simon Clubley <clubley@remove_me.eisner.decus.org- > > > 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? > > 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.
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.
> > 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. > > It was always clear to me, I think the openocd manual is very good > actually.
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. Rick