Freescale's Idea of Open Source JTAG

  • Permalink
  • submit to reddit
  • Email
  • Follow


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
0
Reply rickman 3/19/2011 4:22:38 PM

See related articles to this posting


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
0
Reply Simon 3/19/2011 4:52:48 PM

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
0
Reply Anders 3/19/2011 5:30:54 PM

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
0
Reply Anders 3/19/2011 5:37:26 PM

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
0
Reply rickman 3/19/2011 5:57:59 PM

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
0
Reply rickman 3/19/2011 6:09:06 PM

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
0
Reply Anders 3/19/2011 6:20:03 PM

On 2011-03-19, rickman <gnuarm@gmail.com> wrote:
> On Mar 19, 12:52�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
0
Reply Simon 3/19/2011 6:49:31 PM

rickman <gnuarm@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.

> 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
0
Reply John 3/19/2011 6:58:51 PM

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
0
Reply rickman 3/19/2011 7:52:54 PM

On Mar 19, 2:49=A0pm, Simon Clubley <clubley@remove_me.eisner.decus.org-
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
independent.


> 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 boa=
rd
> 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
> memory.
>
> Therefore if I am running a debugger (I use the ddd frontend to gdb),
> the comms path looks like this:
>
> =A0 =A0 =A0 =A0 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
mystery!

Rick
0
Reply rickman 3/19/2011 8:01:08 PM

On 2011-03-19, rickman <gnuarm@gmail.com> wrote:
> On Mar 19, 2:58 pm, John Devereux <j...@devereux.me.uk> wrote:
>>
>> 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.
>

I can understand your confusion. The reason I referred to a "ARM-JTAG cable"
was because I was referring to a specific product:

	http://olimex.com/dev/arm-jtag.html

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.

> 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?
>

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
0
Reply Simon 3/19/2011 8:39:25 PM

On 2011-03-19, rickman <gnuarm@gmail.com> wrote:
> On Mar 19, 2:49�pm, Simon Clubley <clubley@remove_me.eisner.decus.org-
> 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
> independent.
>

Yes, it is JTAG only and it is the only tool in the chain I mentioned
which has specific JTAG knowledge.

>
>> 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?
>

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.

>
>> 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?
>

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.

>
>> 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.
>
> Thanks.  I'm not looking for JTAG debugging 101.  I have used JTAG

Sorry. :-)

> 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!
>

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
0
Reply Simon 3/19/2011 9:04:11 PM

On 2011-03-19, rickman <gnuarm@gmail.com> wrote:
> On Mar 19, 2:49?pm, Simon Clubley <clubley@remove_me.eisner.decus.org-
> Earth.UFP> wrote:
>> 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?

GDB is primarily a desktop debugger for hosted applications running
natively.  It needs extensions for embedded work.

-- 
Andrew Smallshaw
andrews@sdf.lonestar.org
0
Reply Andrew 3/19/2011 9:11:37 PM

On 2011-03-19, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>
> The JTAG adapter and driver are implemented within (and only within)
> OpenOCD.
>

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
0
Reply Simon 3/19/2011 9:25:12 PM

On 19/03/11 22:25, Simon Clubley wrote:
> On 2011-03-19, Simon Clubley<clubley@remove_me.eisner.decus.org-Earth.UFP>  wrote:
>>
>> The JTAG adapter and driver are implemented within (and only within)
>> OpenOCD.
>>
>
> 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.
>

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.




0
Reply David 3/19/2011 10:21:10 PM

On 19/03/11 19:20, Anders.Montonen@kapsi.spam.stop.fi.invalid wrote:
> 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.
>


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).
0
Reply David 3/19/2011 10:36:05 PM

On Mar 19, 4:39=A0pm, Simon Clubley <clubley@remove_me.eisner.decus.org-
Earth.UFP> wrote:
> On 2011-03-19, rickman <gnu...@gmail.com> wrote:
>
>
>
> > On Mar 19, 2:58 pm, John Devereux <j...@devereux.me.uk> wrote:
>
> >> 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. =A0I think the example I gave is very
> > illustrative. =A0But that is not the point, or at least my point. =A0I =
am
> > trying to come up the learning curve. =A0BTW, part of the problem is
> > terminology. =A0For example, Simon's reply talks about using an "ARM-
> > JTAG cable" when it would be more clear if he said a JTAG adapter. =A0H=
e
> > 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. =A0The terms
> > JTAG and Debugger are used for everything so that it is hard to tell
> > what is being discussed.
>
> I can understand your confusion. The reason I referred to a "ARM-JTAG cab=
le"
> was because I was referring to a specific product:
>
> =A0 =A0 =A0 =A0http://olimex.com/dev/arm-jtag.html
>
> 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.
>
>
>
> > 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. =A0There 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. =A0I'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. =A0Outside 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? =A0What it the protocol between them?
> > How does this protocol relate to the target? =A0Is it at all target
> > specific? =A0Which of the layers are target specific?
>
> 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:
>
> =A0 =A0 =A0 =A0 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.

Thank you, that helps tremendously.

Rick
0
Reply rickman 3/20/2011 2:33:16 AM

On Mar 19, 6:36=A0pm, David Brown <david.br...@removethis.hesbynett.no>
wrote:
> On 19/03/11 19:20, Anders.Monto...@kapsi.spam.stop.fi.invalid wrote:
>
> > rickman<gnu...@gmail.com> =A0wrote:
> >> I just want to understand the whole tool chain for debugging. =A0I als=
o
> >> 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 s=
ome
> > tools for Freescale's 8/16-bit micros). There's been some talk of suppo=
rt
> > 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.
>
> The OSBDM devices apparently use the same protocol as P&E Micro debugger
> cables. =A0As far as I could see, OpenOCD doesn't support that (as yet).

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?

> CodeSourcery's gcc toolchain /does/ support Kinetis and OSBDM debugging
> using debug sprites. =A0These 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).

So where do sprites connect into the chain as outlined by Simon?  Do
they connect to OpenOCD or directly to GDB?

Rick
0
Reply rickman 3/20/2011 2:44:26 AM

On Mar 19, 6:21 pm, David Brown <david.br...@removethis.hesbynett.no>
wrote:
> On 19/03/11 22:25, Simon Clubley wrote:
>
>
>
> > On 2011-03-19, Simon Clubley<clubley@remove_me.eisner.decus.org-Earth.UFP>  wrote:
>
> >> The JTAG adapter and driver are implemented within (and only within)
> >> OpenOCD.
>
> > 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.
>
> 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.

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.

Rick
0
Reply rickman 3/20/2011 5:06:41 AM

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:


[...]

>
> 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.

Hi Simon,

Do you like ddd? I only ever tried it briefly years ago. I always used
insight but perhaps it's worth looking again?

> 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.

Of course it can run on a remote machine too - gdb can be on a desktop
and openocd on a laptop with the jtag dongle say.

[...]


-- 

John Devereux
0
Reply John 3/20/2011 10:17:32 AM

On 20/03/11 06:06, rickman wrote:
> On Mar 19, 6:21 pm, David Brown<david.br...@removethis.hesbynett.no>
> wrote:
>> On 19/03/11 22:25, Simon Clubley wrote:
>>
>>
>>
>>> On 2011-03-19, Simon Clubley<clubley@remove_me.eisner.decus.org-Earth.UFP>   wrote:
>>
>>>> The JTAG adapter and driver are implemented within (and only within)
>>>> OpenOCD.
>>
>>> 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.
>>
>> 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.
>
> 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.
>

That's possibly correct - but remember that "open source" doesn't 
necessarily mean "documented", "well-written" or "understandable".  Many 
developers who publish their source are proud of their work, and want 
people to view their code and think it is well written, and also want to 
write code that other people can work with an contribute to.  But that 
doesn't apply to all open source code, especially if it has been written 
as an internal project and then later released without due care and 
planning.  I have no idea what the situation is for Freescale's code 
here - I am just saying that even if the code is available, it does not 
mean the OpenOCD developers can trivially support the interface.

> 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

Yes, that is GBD's protocol.  It is documented in the gdb documentation, 
if you are interested in the details:

<http://sourceware.org/gdb/current/onlinedocs/gdb/>
<http://sourceware.org/gdb/current/onlinedocs/gdb/Remote-Protocol.html#Remote-Protocol>

> 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

Yes, it is OpenOCD that handles this - though possibly in cooperation 
with "intelligent" debugger hardware interfaces.  For simple interfaces 
such as the FTDI-based devices, OpenOCD handles all the translation 
between gdb protocol telegrams (such as "read 4 bytes from address 
0x1234") into the required jtag telegrams for the particular target.

> 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?
>

I don't know whether the OSJTAG does any work itself, or passes things 
on directly.  But either way, one would hope there is enough 
documentation available to allow OpenOCD to speak to the OSJTAG - if 
not, then reverse engineering based on the source code for OSJTAG is 
certainly possible.

> 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.

Yes, that's about right.

Of course, there is another possible route.  The Kinetis development 
cards have a standard ARM jtag port, as far as I can see, in addition to 
the OSJTAG USB device.  So you can use any other Cortex-compatible 
debugger with them - ranging from powerful "intelligent" devices like 
the ZY1000 to cheap (or even home-made) FTDI-based devices.  So while I 
hope that OSJTAG support will make its way into OpenOCD sometime (and if 
Freescale are on the ball, they will contribute to that work 
themselves), you can always get around it with some cheap and simple 
hardware.


0
Reply David 3/20/2011 1:40:02 PM

On 20/03/11 03:44, rickman wrote:
> On Mar 19, 6:36 pm, David Brown<david.br...@removethis.hesbynett.no>
> wrote:
>> On 19/03/11 19:20, Anders.Monto...@kapsi.spam.stop.fi.invalid wrote:
>>
>>> rickman<gnu...@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.
>>
>> 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).
>
> Is this protocol open?  If I understand correctly, the OSJTAG(OSBDM)
> adapter source code is open source although I have not verified what

I don't know if it is open or not, or if it is documented or not.

> 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?
>

Yes, it would be something like that.

>> 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).
>
> So where do sprites connect into the chain as outlined by Simon?  Do
> they connect to OpenOCD or directly to GDB?
>

The sprites connect directly to gdb - CodeSourcery's arrangement doesn't 
use OpenOCD.  Of course, you can choose to use OpenOCD instead of 
CodeSourcery's sprites if you prefer (assuming OpenOCD supports your 
debugger hardware...).

As a general point I'd recommend CodeSourcery as a source of gcc 
toolchains for embedded systems.  Their packages range from free, 
through cheap, to expensive (depending on the level of support you want, 
extra libraries, etc.).  But they do much of the work in gcc development 
for various embedded architectures, so you are supporting the people who 
make the code, and you get support from the people who wrote it.


0
Reply David 3/20/2011 1:45:20 PM

On 2011-03-20, John Devereux <john@devereux.me.uk> wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>
>
> [...]
>
>>
>> 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.
>
> Hi Simon,
>
> Do you like ddd? I only ever tried it briefly years ago. I always used
> insight but perhaps it's worth looking again?
>

It falls into the category of acceptable (at least for my requirements)
but I mildly prefer the Insight interface.

I have switched to ddd because of the development situation with Insight.
Insight uses it's own copy of the gdb code and I could not see a way of
making Insight build against a later version of the gdb code base.
Comments made on the gdb or Insight mailing lists by the developers also
implied that this was not possible as well.

(I tried to replace the Insight supplied version of gdb with the code from
a later gdb version anyway, but the build failed. I didn't spend much
time on it because I had already decided to start looking for a new
front end.)

When Insight was still actively been worked on this was not a problem
because you had frequent releases to correspond with the standalone releases
of gdb. However, work on Insight has slowed down over the last couple of
years and the latest released version of Insight still only contains gdb 6.8.

The ARM cross compiler toolchain I am using uses gdb 7.1 as it's debugger
and I am also wanting to look at using the gdb support in RTEMS in the
future. This latter requirement really forced the issue because OAR (the
creators of RTEMS) supply patches for gdb and these are targetted against
a specific gdb version.

At this point, I realised that this tight integration of a increasingly
stale gdb version with Insight was going to become more and more of a
issue in the future and I decided to switch away from Insight to a
front end which communicated with a seperate gdb process using the
gdb machine interface.

I looked at a range of alternatives and ddd was the best of the front ends
which supported remote target debugging (not all of the front ends
support remote target debugging).

I did look briefly at Nemiver but I didn't bother trying to compile it as
it didn't offer anything over ddd and it's remote debugging support looks
to be a work in progress. For example, from the Nemiver FAQ:

|How to make Nemiver use a GDB that I have compiled
|
|Once you've compiled your version of version of GDB and installed it to
|/path/to/your/gdb, you can make Nemiver use it by setting a gconf key:
|
|gconftool-2 --set --type string  /apps/nemiver/dbgperspective/gdb-binary /path/to/your/gdb
|
|Why isn't there a UI to make Nemiver use the GDB that I have compiled
|
|Because nobody had the time to write that UI yet. Well. That code has been
|written now but it hasn't been released yet. Try nemiver from the master git
|repository to enjoy it.

With ddd, I can just specify which gdb to use on the command line and hence
easily switch between a native gdb and a cross compiled gdb.

There's also a emphasis on using GUI menus (for example to connect to the
remote target) instead of been able to specify those options on the command
line which is something I really dislike. With ddd, I can just pass in the
name of a gdb script which does the connect for me, but according to the
Nemiver manual:

|2.3.4.2. Using the Command Line
|
|Nemiver does not provide a way to connect to a remote server using the
|command line 

Finally, I didn't like the fact that Nemiver requires a full range of
Gnome libraries.

BTW, if you ever find yourself at the end of a slow terminal session and
need to debug something, there's a curses based gdb front end which is
better than the one supplied with gdb. It can be found at:

	http://cgdb.sourceforge.net/

Keeping in mind the limitations of a curses based interface, it's actually
quite a nice little front end for certain situations.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Reply Simon 3/20/2011 3:47:06 PM

On Mar 20, 9:40=A0am, David Brown <david.br...@removethis.hesbynett.no>
wrote:
>
> Of course, there is another possible route. =A0The Kinetis development
> cards have a standard ARM jtag port, as far as I can see, in addition to
> the OSJTAG USB device. =A0So you can use any other Cortex-compatible
> debugger with them - ranging from powerful "intelligent" devices like
> the ZY1000 to cheap (or even home-made) FTDI-based devices. =A0So while I
> hope that OSJTAG support will make its way into OpenOCD sometime (and if
> Freescale are on the ball, they will contribute to that work
> themselves), you can always get around it with some cheap and simple
> hardware.

Ok, that brings me to another question.  If a more conventional JTAG
adapter is uses, say something very dumb like a wiggler, I assume that
OpenOCD then needs to be modified for the specific targets to be
supported.  In the case of the Kinetis devices, I expect supporting
one would be pretty much like supporting them all.  But this is not
likely to be the same as support for other Cortex M3/4 devices, or
will it be the same?

I want to work with a developer who currently supports several CM3
devices.  I want to find a way to get him the debugging support he
wants so that he will support the CM4 Kinetis devices.  He has said he
wants to work with OpenOCD.  He mentioned something about Code Red not
being his favorite.  I guess Code Red is an alternative to OpenOCD?

If the Freescale supported debugging is through sprites with GDB this
may not be what he wants.  I'll have to ask some intelligent questions
now that I understand the issues better.

Thanks to everyone for all the info and advice.

Rick
0
Reply rickman 3/20/2011 5:18:36 PM

On 20/03/11 18:18, rickman wrote:
> On Mar 20, 9:40 am, David Brown<david.br...@removethis.hesbynett.no>
> wrote:
>>
>> Of course, there is another possible route.  The Kinetis development
>> cards have a standard ARM jtag port, as far as I can see, in addition to
>> the OSJTAG USB device.  So you can use any other Cortex-compatible
>> debugger with them - ranging from powerful "intelligent" devices like
>> the ZY1000 to cheap (or even home-made) FTDI-based devices.  So while I
>> hope that OSJTAG support will make its way into OpenOCD sometime (and if
>> Freescale are on the ball, they will contribute to that work
>> themselves), you can always get around it with some cheap and simple
>> hardware.
>
> Ok, that brings me to another question.  If a more conventional JTAG
> adapter is uses, say something very dumb like a wiggler, I assume that
> OpenOCD then needs to be modified for the specific targets to be
> supported.  In the case of the Kinetis devices, I expect supporting
> one would be pretty much like supporting them all.  But this is not
> likely to be the same as support for other Cortex M3/4 devices, or
> will it be the same?
>

One of the nice things about the Cortex (as distinct from previous ARM 
cores) is that the debug module is a fundamental part of Cortex, rather 
than being made or adapted by the chip designer.  So all Cortex debug 
blocks will be compatible and follow the same standards.  Thus once you 
support one Cortex, you support them all.  At least, that applies within 
the Cortex family group (such as M3/4) - I can't be sure if it is the 
same for Cortex A or R devices.  Some devices may have extra debug 
facilities, but the basic jtag debugging interface is always the same.

There are some things that vary between target systems, such as the 
memory layout and flash types.  OpenOCD also supports flash programming 
and other sorts of board initialisation (such as clock configuration, 
disabling watchdogs, etc.).  This needs to be specific for different 
systems, but it is mostly handled by initialisation scripts rather than 
changes to OpenOCD code.  Significant differences in flash programming 
algorithms may need changes to the OpenOCD code, however.

> I want to work with a developer who currently supports several CM3
> devices.  I want to find a way to get him the debugging support he
> wants so that he will support the CM4 Kinetis devices.  He has said he
> wants to work with OpenOCD.  He mentioned something about Code Red not
> being his favorite.  I guess Code Red is an alternative to OpenOCD?
>

Code Red is a commercial gcc toolchain vendor (like CodeSourcery).  They 
package gcc, a library (I don't know if it is their own library, or 
something general like newlib), an IDE (I guess Eclipse) and debugger in 
a paid-for and supported packaging.  I haven't used it, but it seems to 
be quite popular in the USA.  I would guess that Code Red uses OpenOCD 
as a gdb proxy for debugging, though maybe they have their own system 
(as CodeSourcery does).

> If the Freescale supported debugging is through sprites with GDB this
> may not be what he wants.  I'll have to ask some intelligent questions
> now that I understand the issues better.
>

As I said earlier, you can connect a normal external jtag interface 
cable to the Kinetis cards and use that along with OpenOCD.  And the 
micros themselves certainly have the standard ARM Cortex jtag debugging 
port.  The only question is whether you can use the onboard USB-to-jtag 
interface on the Tower development boards.  You /can/ do that if you use 
CodeSourcery and pay for the use of their sprites.  You /cannot/ do it 
with OpenOCD at the moment.  OpenOCD will probably get support for them, 
if it is not to hard to do, but it is not there yet.

But for now, the easiest answer is probably to buy a cheap FTDI-based 
debugger and use that with OpenOCD - just ignore the Tower's USB-to-jtag 
interface entirely.

> Thanks to everyone for all the info and advice.
>
> Rick

0
Reply David 3/20/2011 8:05:20 PM

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> On 2011-03-20, John Devereux <john@devereux.me.uk> wrote:
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

[...]

>> Hi Simon,
>>
>> Do you like ddd? I only ever tried it briefly years ago. I always used
>> insight but perhaps it's worth looking again?
>>
>
> It falls into the category of acceptable (at least for my requirements)
> but I mildly prefer the Insight interface.
>
> I have switched to ddd because of the development situation with Insight.
> Insight uses it's own copy of the gdb code and I could not see a way of
> making Insight build against a later version of the gdb code base.
> Comments made on the gdb or Insight mailing lists by the developers also
> implied that this was not possible as well.
>
> (I tried to replace the Insight supplied version of gdb with the code from
> a later gdb version anyway, but the build failed. I didn't spend much
> time on it because I had already decided to start looking for a new
> front end.)
>
> When Insight was still actively been worked on this was not a problem
> because you had frequent releases to correspond with the standalone releases
> of gdb. However, work on Insight has slowed down over the last couple of
> years and the latest released version of Insight still only contains gdb 6.8.

I'm using a slightly newer version (unreleased I guess) 7.0.50.

> The ARM cross compiler toolchain I am using uses gdb 7.1 as it's debugger
> and I am also wanting to look at using the gdb support in RTEMS in the
> future. This latter requirement really forced the issue because OAR (the
> creators of RTEMS) supply patches for gdb and these are targetted against
> a specific gdb version.
>
> At this point, I realised that this tight integration of a increasingly
> stale gdb version with Insight was going to become more and more of a
> issue in the future and I decided to switch away from Insight to a
> front end which communicated with a seperate gdb process using the
> gdb machine interface.

This does seems like a good move. Insight 7.0.50 works for me at the
moment but I will give ddd another try. And David seems to like text
mode gdb, perhaps I should just get used to that! I'm starting to use
bits of it more anyway, like recently for printing arrays.

> I looked at a range of alternatives and ddd was the best of the front ends
> which supported remote target debugging (not all of the front ends
> support remote target debugging).
>
> I did look briefly at Nemiver but I didn't bother trying to compile it as
> it didn't offer anything over ddd and it's remote debugging support looks
> to be a work in progress. For example, from the Nemiver FAQ:
>
> |How to make Nemiver use a GDB that I have compiled
> |
> |Once you've compiled your version of version of GDB and installed it to
> |/path/to/your/gdb, you can make Nemiver use it by setting a gconf key:
> |
> |gconftool-2 --set --type string  /apps/nemiver/dbgperspective/gdb-binary /path/to/your/gdb
> |
> |Why isn't there a UI to make Nemiver use the GDB that I have compiled
> |
> |Because nobody had the time to write that UI yet. Well. That code has been
> |written now but it hasn't been released yet. Try nemiver from the master git
> |repository to enjoy it.
>
> With ddd, I can just specify which gdb to use on the command line and hence
> easily switch between a native gdb and a cross compiled gdb.
> There's also a emphasis on using GUI menus (for example to connect to the
> remote target) instead of been able to specify those options on the command
> line which is something I really dislike. With ddd, I can just pass in the
> name of a gdb script which does the connect for me, but according to the
> Nemiver manual:


Yes, I have a .gdbinit which connects to the target and defines various
macros for programming and reset control.

> |2.3.4.2. Using the Command Line
> |
> |Nemiver does not provide a way to connect to a remote server using the
> |command line 
>
> Finally, I didn't like the fact that Nemiver requires a full range of
> Gnome libraries.
>
> BTW, if you ever find yourself at the end of a slow terminal session and
> need to debug something, there's a curses based gdb front end which is
> better than the one supplied with gdb. It can be found at:
>
> 	http://cgdb.sourceforge.net/
>
> Keeping in mind the limitations of a curses based interface, it's actually
> quite a nice little front end for certain situations.
>
> Simon.

-- 

John Devereux
0
Reply John 3/20/2011 9:00:54 PM

On Mar 20, 4:05=A0pm, David Brown <david.br...@removethis.hesbynett.no>
wrote:
> On 20/03/11 18:18, rickman wrote:
>
> > On Mar 20, 9:40 am, David Brown<david.br...@removethis.hesbynett.no>
> > wrote:
>
> >> Of course, there is another possible route. =A0The Kinetis development
> >> cards have a standard ARM jtag port, as far as I can see, in addition =
to
> >> the OSJTAG USB device. =A0So you can use any other Cortex-compatible
> >> debugger with them - ranging from powerful "intelligent" devices like
> >> the ZY1000 to cheap (or even home-made) FTDI-based devices. =A0So whil=
e I
> >> hope that OSJTAG support will make its way into OpenOCD sometime (and =
if
> >> Freescale are on the ball, they will contribute to that work
> >> themselves), you can always get around it with some cheap and simple
> >> hardware.
>
> > Ok, that brings me to another question. =A0If a more conventional JTAG
> > adapter is uses, say something very dumb like a wiggler, I assume that
> > OpenOCD then needs to be modified for the specific targets to be
> > supported. =A0In the case of the Kinetis devices, I expect supporting
> > one would be pretty much like supporting them all. =A0But this is not
> > likely to be the same as support for other Cortex M3/4 devices, or
> > will it be the same?
>
> One of the nice things about the Cortex (as distinct from previous ARM
> cores) is that the debug module is a fundamental part of Cortex, rather
> than being made or adapted by the chip designer. =A0So all Cortex debug
> blocks will be compatible and follow the same standards. =A0Thus once you
> support one Cortex, you support them all. =A0At least, that applies withi=
n
> the Cortex family group (such as M3/4) - I can't be sure if it is the
> same for Cortex A or R devices. =A0Some devices may have extra debug
> facilities, but the basic jtag debugging interface is always the same.
>
> There are some things that vary between target systems, such as the
> memory layout and flash types. =A0OpenOCD also supports flash programming
> and other sorts of board initialisation (such as clock configuration,
> disabling watchdogs, etc.). =A0This needs to be specific for different
> systems, but it is mostly handled by initialisation scripts rather than
> changes to OpenOCD code. =A0Significant differences in flash programming
> algorithms may need changes to the OpenOCD code, however.

Sure, the target systems will vary, but that is something that will
always be supported by the tools, right?  It is issues with the target
processor I am trying to understand.


> > I want to work with a developer who currently supports several CM3
> > devices. =A0I want to find a way to get him the debugging support he
> > wants so that he will support the CM4 Kinetis devices. =A0He has said h=
e
> > wants to work with OpenOCD. =A0He mentioned something about Code Red no=
t
> > being his favorite. =A0I guess Code Red is an alternative to OpenOCD?
>
> Code Red is a commercial gcc toolchain vendor (like CodeSourcery). =A0The=
y
> package gcc, a library (I don't know if it is their own library, or
> something general like newlib), an IDE (I guess Eclipse) and debugger in
> a paid-for and supported packaging. =A0I haven't used it, but it seems to
> be quite popular in the USA. =A0I would guess that Code Red uses OpenOCD
> as a gdb proxy for debugging, though maybe they have their own system
> (as CodeSourcery does).

He is saying he wants to use OpenOCD rather than Code Red, so I guess
there is some sort of difference there rather than Code Red just
including OpenOCD.


> > If the Freescale supported debugging is through sprites with GDB this
> > may not be what he wants. =A0I'll have to ask some intelligent question=
s
> > now that I understand the issues better.
>
> As I said earlier, you can connect a normal external jtag interface
> cable to the Kinetis cards and use that along with OpenOCD. =A0And the
> micros themselves certainly have the standard ARM Cortex jtag debugging
> port. =A0The only question is whether you can use the onboard USB-to-jtag
> interface on the Tower development boards. =A0You /can/ do that if you us=
e
> CodeSourcery and pay for the use of their sprites. =A0You /cannot/ do it
> with OpenOCD at the moment. =A0OpenOCD will probably get support for them=
,
> if it is not to hard to do, but it is not there yet.
>
> But for now, the easiest answer is probably to buy a cheap FTDI-based
> debugger and use that with OpenOCD - just ignore the Tower's USB-to-jtag
> interface entirely.

I understand that the standard JTAG connector is there, but do we know
that the Kinetis target is supported by OpenOCD?  I guess you are
saying that all CM3/4 variants are supported because of the common
nature of the debugging module in the processor.

On a slightly different note, if I have an embedded processor in an
FPGA which I add a JTAG interface to for debugging, how do I get that
to work with OpenOCD?  Is there any documentation on how this tool
works with the debugging hardware (the target, not the JTAG adapter)?

Rick
0
Reply rickman 3/21/2011 1:22:02 PM

On 21/03/2011 14:22, rickman wrote:
> On Mar 20, 4:05 pm, David Brown<david.br...@removethis.hesbynett.no>
> wrote:
>> On 20/03/11 18:18, rickman wrote:
>>
>>> On Mar 20, 9:40 am, David Brown<david.br...@removethis.hesbynett.no>
>>> wrote:
>>
>>>> Of course, there is another possible route.  The Kinetis development
>>>> cards have a standard ARM jtag port, as far as I can see, in addition to
>>>> the OSJTAG USB device.  So you can use any other Cortex-compatible
>>>> debugger with them - ranging from powerful "intelligent" devices like
>>>> the ZY1000 to cheap (or even home-made) FTDI-based devices.  So while I
>>>> hope that OSJTAG support will make its way into OpenOCD sometime (and if
>>>> Freescale are on the ball, they will contribute to that work
>>>> themselves), you can always get around it with some cheap and simple
>>>> hardware.
>>
>>> Ok, that brings me to another question.  If a more conventional JTAG
>>> adapter is uses, say something very dumb like a wiggler, I assume that
>>> OpenOCD then needs to be modified for the specific targets to be
>>> supported.  In the case of the Kinetis devices, I expect supporting
>>> one would be pretty much like supporting them all.  But this is not
>>> likely to be the same as support for other Cortex M3/4 devices, or
>>> will it be the same?
>>
>> One of the nice things about the Cortex (as distinct from previous ARM
>> cores) is that the debug module is a fundamental part of Cortex, rather
>> than being made or adapted by the chip designer.  So all Cortex debug
>> blocks will be compatible and follow the same standards.  Thus once you
>> support one Cortex, you support them all.  At least, that applies within
>> the Cortex family group (such as M3/4) - I can't be sure if it is the
>> same for Cortex A or R devices.  Some devices may have extra debug
>> facilities, but the basic jtag debugging interface is always the same.
>>
>> There are some things that vary between target systems, such as the
>> memory layout and flash types.  OpenOCD also supports flash programming
>> and other sorts of board initialisation (such as clock configuration,
>> disabling watchdogs, etc.).  This needs to be specific for different
>> systems, but it is mostly handled by initialisation scripts rather than
>> changes to OpenOCD code.  Significant differences in flash programming
>> algorithms may need changes to the OpenOCD code, however.
>
> Sure, the target systems will vary, but that is something that will
> always be supported by the tools, right?  It is issues with the target
> processor I am trying to understand.
>

There should not be any issues with the target processor, as far as I 
know.  I haven't tried the Kinetis (or any other M4 chip) as yet, so I 
have no guarantees - only the expectations I have based on my reading. 
The Cortex devices have the same base debug features (there are optional 
extras, such as ETM), so any debugger that supports one Cortex M device 
through jtag should support them all.

>
>>> I want to work with a developer who currently supports several CM3
>>> devices.  I want to find a way to get him the debugging support he
>>> wants so that he will support the CM4 Kinetis devices.  He has said he
>>> wants to work with OpenOCD.  He mentioned something about Code Red not
>>> being his favorite.  I guess Code Red is an alternative to OpenOCD?
>>
>> Code Red is a commercial gcc toolchain vendor (like CodeSourcery).  They
>> package gcc, a library (I don't know if it is their own library, or
>> something general like newlib), an IDE (I guess Eclipse) and debugger in
>> a paid-for and supported packaging.  I haven't used it, but it seems to
>> be quite popular in the USA.  I would guess that Code Red uses OpenOCD
>> as a gdb proxy for debugging, though maybe they have their own system
>> (as CodeSourcery does).
>
> He is saying he wants to use OpenOCD rather than Code Red, so I guess
> there is some sort of difference there rather than Code Red just
> including OpenOCD.
>

That's like saying "I'd rather use a manual gearbox than a Volvo".  Code 
Red is a company that sells commercially-supported gcc-based embedded 
toolchains; OpenOCD is a commonly used proxy program to allow gdb to 
talk to jtag interface hardware.  They are different things.

I've looked a little at Code Red's website - it seems that they have 
their own non-open-source proxy programs (much like CodeSourcery), 
rather than using OpenOCD.  It could be that your developer means "I 
want to use OpenOCD rather than Code Red's own gdb proxy software".  If 
that's not what he means, then you should worry about the developer.

>
>>> If the Freescale supported debugging is through sprites with GDB this
>>> may not be what he wants.  I'll have to ask some intelligent questions
>>> now that I understand the issues better.
>>
>> As I said earlier, you can connect a normal external jtag interface
>> cable to the Kinetis cards and use that along with OpenOCD.  And the
>> micros themselves certainly have the standard ARM Cortex jtag debugging
>> port.  The only question is whether you can use the onboard USB-to-jtag
>> interface on the Tower development boards.  You /can/ do that if you use
>> CodeSourcery and pay for the use of their sprites.  You /cannot/ do it
>> with OpenOCD at the moment.  OpenOCD will probably get support for them,
>> if it is not to hard to do, but it is not there yet.
>>
>> But for now, the easiest answer is probably to buy a cheap FTDI-based
>> debugger and use that with OpenOCD - just ignore the Tower's USB-to-jtag
>> interface entirely.
>
> I understand that the standard JTAG connector is there, but do we know
> that the Kinetis target is supported by OpenOCD?  I guess you are
> saying that all CM3/4 variants are supported because of the common
> nature of the debugging module in the processor.
>

Yes, that is my understanding.

> On a slightly different note, if I have an embedded processor in an
> FPGA which I add a JTAG interface to for debugging, how do I get that
> to work with OpenOCD?  Is there any documentation on how this tool
> works with the debugging hardware (the target, not the JTAG adapter)?
>

Making a JTAG TAP interface in an FPGA is not trivial, and using the 
FPGA's JTAG with embedded processors is also complicated unless it is 
within the FPGA development tools (e.g., if you put a NIOS II in an 
Altera FPGA, and connect it to the PC using an Altera ByteBlaster, then 
Altera's gdb proxy will let you debug using gdb).  If you want to go 
outside the FPGA development tools, then you are going to have to do a 
fair amount of studying of the documentation for your embedded core and 
its debug facilities - you are getting well beyond what you can solve 
with a few questions on a newsgroup.

mvh.,

David
0
Reply David 3/21/2011 3:12:15 PM

On Mar 21, 11:12=A0am, David Brown <da...@westcontrol.removethisbit.com>
wrote:
> On 21/03/2011 14:22, rickman wrote:
>
> > He is saying he wants to use OpenOCD rather than Code Red, so I guess
> > there is some sort of difference there rather than Code Red just
> > including OpenOCD.
>
> That's like saying "I'd rather use a manual gearbox than a Volvo". =A0Cod=
e
> Red is a company that sells commercially-supported gcc-based embedded
> toolchains; OpenOCD is a commonly used proxy program to allow gdb to
> talk to jtag interface hardware. =A0They are different things.
>
> I've looked a little at Code Red's website - it seems that they have
> their own non-open-source proxy programs (much like CodeSourcery),
> rather than using OpenOCD. =A0It could be that your developer means "I
> want to use OpenOCD rather than Code Red's own gdb proxy software". =A0If
> that's not what he means, then you should worry about the developer.

Why on earth would you think he means anything different?


> > I understand that the standard JTAG connector is there, but do we know
> > that the Kinetis target is supported by OpenOCD? =A0I guess you are
> > saying that all CM3/4 variants are supported because of the common
> > nature of the debugging module in the processor.
>
> Yes, that is my understanding.
>
> > On a slightly different note, if I have an embedded processor in an
> > FPGA which I add a JTAG interface to for debugging, how do I get that
> > to work with OpenOCD? =A0Is there any documentation on how this tool
> > works with the debugging hardware (the target, not the JTAG adapter)?
>
> Making a JTAG TAP interface in an FPGA is not trivial, and using the
> FPGA's JTAG with embedded processors is also complicated unless it is
> within the FPGA development tools (e.g., if you put a NIOS II in an
> Altera FPGA, and connect it to the PC using an Altera ByteBlaster, then
> Altera's gdb proxy will let you debug using gdb). =A0If you want to go
> outside the FPGA development tools, then you are going to have to do a
> fair amount of studying of the documentation for your embedded core and
> its debug facilities - you are getting well beyond what you can solve
> with a few questions on a newsgroup.

You are stressing as difficult the parts I have full control over.  A
JTAG TAP is not a complex piece of design.  That is well within my
capabilities, as long as I understand the requirements.  The rest of
the design is fully mine.  The part I know little about is on the
other side of the JTAG adapter.

I expect the debugging capability in the FPGA would be the same sort
of basic functionality any debug hardware would include; a means of
single stepping at the machine instruction level, breakpoint at an
address for instruction fetch or data read/write, read/write memory
and registers, perhaps even a trace buffer.  If the JTAG interface is
fully defined for some simple processor I am sure duplicating that
functionality would not be at all hard.  The closer I can get to the
functionality of a currently supported processor, the fewer changes to
the software I will need.

Rick
0
Reply rickman 3/21/2011 4:28:51 PM

On 21/03/2011 17:28, rickman wrote:
> On Mar 21, 11:12 am, David Brown<da...@westcontrol.removethisbit.com>
> wrote:
>> On 21/03/2011 14:22, rickman wrote:
>>
>>> He is saying he wants to use OpenOCD rather than Code Red, so I guess
>>> there is some sort of difference there rather than Code Red just
>>> including OpenOCD.
>>
>> That's like saying "I'd rather use a manual gearbox than a Volvo".  Code
>> Red is a company that sells commercially-supported gcc-based embedded
>> toolchains; OpenOCD is a commonly used proxy program to allow gdb to
>> talk to jtag interface hardware.  They are different things.
>>
>> I've looked a little at Code Red's website - it seems that they have
>> their own non-open-source proxy programs (much like CodeSourcery),
>> rather than using OpenOCD.  It could be that your developer means "I
>> want to use OpenOCD rather than Code Red's own gdb proxy software".  If
>> that's not what he means, then you should worry about the developer.
>
> Why on earth would you think he means anything different?
>

I /didn't/ think he meant anything different - but I thought it was 
worth your while checking.  All you said was "he wants to use OpenOCD 
rather than Code Red" - so that was all I had to go on.

>
>>> I understand that the standard JTAG connector is there, but do we know
>>> that the Kinetis target is supported by OpenOCD?  I guess you are
>>> saying that all CM3/4 variants are supported because of the common
>>> nature of the debugging module in the processor.
>>
>> Yes, that is my understanding.
>>
>>> On a slightly different note, if I have an embedded processor in an
>>> FPGA which I add a JTAG interface to for debugging, how do I get that
>>> to work with OpenOCD?  Is there any documentation on how this tool
>>> works with the debugging hardware (the target, not the JTAG adapter)?
>>
>> Making a JTAG TAP interface in an FPGA is not trivial, and using the
>> FPGA's JTAG with embedded processors is also complicated unless it is
>> within the FPGA development tools (e.g., if you put a NIOS II in an
>> Altera FPGA, and connect it to the PC using an Altera ByteBlaster, then
>> Altera's gdb proxy will let you debug using gdb).  If you want to go
>> outside the FPGA development tools, then you are going to have to do a
>> fair amount of studying of the documentation for your embedded core and
>> its debug facilities - you are getting well beyond what you can solve
>> with a few questions on a newsgroup.
>
> You are stressing as difficult the parts I have full control over.  A
> JTAG TAP is not a complex piece of design.  That is well within my
> capabilities, as long as I understand the requirements.  The rest of
> the design is fully mine.  The part I know little about is on the
> other side of the JTAG adapter.
>

OK.  Your viewpoint is as an FPGA expert moving more into 
microcontroller fields, while mine is from long experience with 
microcontrollers and only dabbling in FPGA design.

> I expect the debugging capability in the FPGA would be the same sort
> of basic functionality any debug hardware would include; a means of
> single stepping at the machine instruction level, breakpoint at an
> address for instruction fetch or data read/write, read/write memory
> and registers, perhaps even a trace buffer.  If the JTAG interface is
> fully defined for some simple processor I am sure duplicating that
> functionality would not be at all hard.  The closer I can get to the
> functionality of a currently supported processor, the fewer changes to
> the software I will need.
>

I don't know what processor core you are thinking of on the FPGA, but 
using a pre-built one with a ready-made debug interface will save you a 
lot of effort (assuming, of course, that such cores will do what you 
need).  If you are already planning on using Cortex M4 devices, then the 
obvious choice for an FPGA core would be a Cortex M1.  But you probably 
already know more about these than I do.
0
Reply David 3/22/2011 8:05:50 AM

On Mar 22, 4:05=A0am, David Brown <da...@westcontrol.removethisbit.com>
wrote:
> On 21/03/2011 17:28, rickman wrote:
>
>
>
> > On Mar 21, 11:12 am, David Brown<da...@westcontrol.removethisbit.com>
> > wrote:
> >> On 21/03/2011 14:22, rickman wrote:
>
> >>> He is saying he wants to use OpenOCD rather than Code Red, so I guess
> >>> there is some sort of difference there rather than Code Red just
> >>> including OpenOCD.
>
> >> That's like saying "I'd rather use a manual gearbox than a Volvo". =A0=
Code
> >> Red is a company that sells commercially-supported gcc-based embedded
> >> toolchains; OpenOCD is a commonly used proxy program to allow gdb to
> >> talk to jtag interface hardware. =A0They are different things.
>
> >> I've looked a little at Code Red's website - it seems that they have
> >> their own non-open-source proxy programs (much like CodeSourcery),
> >> rather than using OpenOCD. =A0It could be that your developer means "I
> >> want to use OpenOCD rather than Code Red's own gdb proxy software". =
=A0If
> >> that's not what he means, then you should worry about the developer.
>
> > Why on earth would you think he means anything different?
>
> I /didn't/ think he meant anything different - but I thought it was
> worth your while checking. =A0All you said was "he wants to use OpenOCD
> rather than Code Red" - so that was all I had to go on.
>
>
>
>
>
> >>> I understand that the standard JTAG connector is there, but do we kno=
w
> >>> that the Kinetis target is supported by OpenOCD? =A0I guess you are
> >>> saying that all CM3/4 variants are supported because of the common
> >>> nature of the debugging module in the processor.
>
> >> Yes, that is my understanding.
>
> >>> On a slightly different note, if I have an embedded processor in an
> >>> FPGA which I add a JTAG interface to for debugging, how do I get that
> >>> to work with OpenOCD? =A0Is there any documentation on how this tool
> >>> works with the debugging hardware (the target, not the JTAG adapter)?
>
> >> Making a JTAG TAP interface in an FPGA is not trivial, and using the
> >> FPGA's JTAG with embedded processors is also complicated unless it is
> >> within the FPGA development tools (e.g., if you put a NIOS II in an
> >> Altera FPGA, and connect it to the PC using an Altera ByteBlaster, the=
n
> >> Altera's gdb proxy will let you debug using gdb). =A0If you want to go
> >> outside the FPGA development tools, then you are going to have to do a
> >> fair amount of studying of the documentation for your embedded core an=
d
> >> its debug facilities - you are getting well beyond what you can solve
> >> with a few questions on a newsgroup.
>
> > You are stressing as difficult the parts I have full control over. =A0A
> > JTAG TAP is not a complex piece of design. =A0That is well within my
> > capabilities, as long as I understand the requirements. =A0The rest of
> > the design is fully mine. =A0The part I know little about is on the
> > other side of the JTAG adapter.
>
> OK. =A0Your viewpoint is as an FPGA expert moving more into
> microcontroller fields, while mine is from long experience with
> microcontrollers and only dabbling in FPGA design.

I guess that is one way to put it.  Certainly my experience with FPGAs
is a lot deeper than with MCUs.  I have lots of experience with MCUs
and DSPs, but I've never really popped open the hood on the tools
having always used vendor supplied tools.  I have literally no
experience with the gnu tools other than that I host the gnuarm.com
site.  But even that is languishing since the guy who used to do the
builds has decided that yagarto is a better way to go and abandoned
the gnuarm effort.  :(  Someday I need to learn how to build and use
the tools so I can update gnuarm.com.


> > I expect the debugging capability in the FPGA would be the same sort
> > of basic functionality any debug hardware would include; a means of
> > single stepping at the machine instruction level, breakpoint at an
> > address for instruction fetch or data read/write, read/write memory
> > and registers, perhaps even a trace buffer. =A0If the JTAG interface is
> > fully defined for some simple processor I am sure duplicating that
> > functionality would not be at all hard. =A0The closer I can get to the
> > functionality of a currently supported processor, the fewer changes to
> > the software I will need.
>
> I don't know what processor core you are thinking of on the FPGA, but
> using a pre-built one with a ready-made debug interface will save you a
> lot of effort (assuming, of course, that such cores will do what you
> need). =A0If you are already planning on using Cortex M4 devices, then th=
e
> obvious choice for an FPGA core would be a Cortex M1. =A0But you probably
> already know more about these than I do.

I plan to gain experience with the Cortex devices.  I have worked with
the Luminary Micro parts, but I think the Kinetis line has longer
legs.  Or at least they seem like they are going into the CM3/4 area
with guns ablaze!  But my real passion at the moment (even if not
financially fruitful) is home grown CPUs in FPGAs.  There are some
interesting approaches to CPUs when done in FPGAs that can take
advantage of a simple architecture as well as various optimizations
available in FPGAs to produce small and fast processors.  I rolled my
own once and used it in a design, but never had decent tool support.

Right now the only thing between me and a good solution seems to be
connecting to available debug tools through JTAG and adding a new
processor to the tool.  Someone I know has done this for some of the
CM3 devices and I am trying to help him with the CM4 Kinetis parts.
Once that goal is reached I figure I'll have enough insight to adapt
the process to my FPGA processors.

I'm not looking to find a shortest path method adding a CPU to an
FPGA.  Those tend to be proprietary and large.  I am looking for open
source all the way to give me enough control that I can optimize for
my needs.

Rick
0
Reply rickman 3/22/2011 1:35:46 PM

On 22/03/2011 14:35, rickman wrote:
> On Mar 22, 4:05 am, David Brown<da...@westcontrol.removethisbit.com>
> wrote:
>> On 21/03/2011 17:28, rickman wrote:
>>
>> OK.  Your viewpoint is as an FPGA expert moving more into
>> microcontroller fields, while mine is from long experience with
>> microcontrollers and only dabbling in FPGA design.
>
> I guess that is one way to put it.  Certainly my experience with FPGAs
> is a lot deeper than with MCUs.  I have lots of experience with MCUs
> and DSPs, but I've never really popped open the hood on the tools
> having always used vendor supplied tools.  I have literally no
> experience with the gnu tools other than that I host the gnuarm.com
> site.  But even that is languishing since the guy who used to do the
> builds has decided that yagarto is a better way to go and abandoned
> the gnuarm effort.  :(  Someday I need to learn how to build and use
> the tools so I can update gnuarm.com.
>

Of course, you could just agree with him and point gnuarm.com users to 
yagarto :-)  But building gcc toolchains is fun, if you have the time.

>
>>> I expect the debugging capability in the FPGA would be the same sort
>>> of basic functionality any debug hardware would include; a means of
>>> single stepping at the machine instruction level, breakpoint at an
>>> address for instruction fetch or data read/write, read/write memory
>>> and registers, perhaps even a trace buffer.  If the JTAG interface is
>>> fully defined for some simple processor I am sure duplicating that
>>> functionality would not be at all hard.  The closer I can get to the
>>> functionality of a currently supported processor, the fewer changes to
>>> the software I will need.
>>
>> I don't know what processor core you are thinking of on the FPGA, but
>> using a pre-built one with a ready-made debug interface will save you a
>> lot of effort (assuming, of course, that such cores will do what you
>> need).  If you are already planning on using Cortex M4 devices, then the
>> obvious choice for an FPGA core would be a Cortex M1.  But you probably
>> already know more about these than I do.
>
> I plan to gain experience with the Cortex devices.  I have worked with
> the Luminary Micro parts, but I think the Kinetis line has longer
> legs.  Or at least they seem like they are going into the CM3/4 area
> with guns ablaze!  But my real passion at the moment (even if not
> financially fruitful) is home grown CPUs in FPGAs.  There are some
> interesting approaches to CPUs when done in FPGAs that can take
> advantage of a simple architecture as well as various optimizations
> available in FPGAs to produce small and fast processors.  I rolled my
> own once and used it in a design, but never had decent tool support.
>

You might be interested to look at the ZPU at 
<http://opensource.zylin.com/zpu.htm>.  This is an open source cpu core 
for FPGAs, with full gcc toolchain support.  I am not sure whether the 
project is still very active (though it is certainly not completely 
dead) - but it might at least give you some ideas.  The main developer 
is coincidentally also very active as an OpenOCD developer, though as 
far as I know there is no OpenOCD (or even JTAG) support for the ZPU.

> Right now the only thing between me and a good solution seems to be
> connecting to available debug tools through JTAG and adding a new
> processor to the tool.  Someone I know has done this for some of the
> CM3 devices and I am trying to help him with the CM4 Kinetis parts.
> Once that goal is reached I figure I'll have enough insight to adapt
> the process to my FPGA processors.
>
> I'm not looking to find a shortest path method adding a CPU to an
> FPGA.  Those tend to be proprietary and large.  I am looking for open
> source all the way to give me enough control that I can optimize for
> my needs.
>
> Rick

0
Reply David 3/22/2011 4:16:41 PM

On Mar 22, 12:16=A0pm, David Brown <da...@westcontrol.removethisbit.com>
wrote:
> On 22/03/2011 14:35, rickman wrote:
>
>
>
> > On Mar 22, 4:05 am, David Brown<da...@westcontrol.removethisbit.com>
> > wrote:
> >> On 21/03/2011 17:28, rickman wrote:
>
> >> OK. =A0Your viewpoint is as an FPGA expert moving more into
> >> microcontroller fields, while mine is from long experience with
> >> microcontrollers and only dabbling in FPGA design.
>
> > I guess that is one way to put it. =A0Certainly my experience with FPGA=
s
> > is a lot deeper than with MCUs. =A0I have lots of experience with MCUs
> > and DSPs, but I've never really popped open the hood on the tools
> > having always used vendor supplied tools. =A0I have literally no
> > experience with the gnu tools other than that I host the gnuarm.com
> > site. =A0But even that is languishing since the guy who used to do the
> > builds has decided that yagarto is a better way to go and abandoned
> > the gnuarm effort. =A0:( =A0Someday I need to learn how to build and us=
e
> > the tools so I can update gnuarm.com.
>
> Of course, you could just agree with him and point gnuarm.com users to
> yagarto :-) =A0But building gcc toolchains is fun, if you have the time.
>
>
>
>
>
> >>> I expect the debugging capability in the FPGA would be the same sort
> >>> of basic functionality any debug hardware would include; a means of
> >>> single stepping at the machine instruction level, breakpoint at an
> >>> address for instruction fetch or data read/write, read/write memory
> >>> and registers, perhaps even a trace buffer. =A0If the JTAG interface =
is
> >>> fully defined for some simple processor I am sure duplicating that
> >>> functionality would not be at all hard. =A0The closer I can get to th=
e
> >>> functionality of a currently supported processor, the fewer changes t=
o
> >>> the software I will need.
>
> >> I don't know what processor core you are thinking of on the FPGA, but
> >> using a pre-built one with a ready-made debug interface will save you =
a
> >> lot of effort (assuming, of course, that such cores will do what you
> >> need). =A0If you are already planning on using Cortex M4 devices, then=
 the
> >> obvious choice for an FPGA core would be a Cortex M1. =A0But you proba=
bly
> >> already know more about these than I do.
>
> > I plan to gain experience with the Cortex devices. =A0I have worked wit=
h
> > the Luminary Micro parts, but I think the Kinetis line has longer
> > legs. =A0Or at least they seem like they are going into the CM3/4 area
> > with guns ablaze! =A0But my real passion at the moment (even if not
> > financially fruitful) is home grown CPUs in FPGAs. =A0There are some
> > interesting approaches to CPUs when done in FPGAs that can take
> > advantage of a simple architecture as well as various optimizations
> > available in FPGAs to produce small and fast processors. =A0I rolled my
> > own once and used it in a design, but never had decent tool support.
>
> You might be interested to look at the ZPU at
> <http://opensource.zylin.com/zpu.htm>. =A0This is an open source cpu core
> for FPGAs, with full gcc toolchain support. =A0I am not sure whether the
> project is still very active (though it is certainly not completely
> dead) - but it might at least give you some ideas. =A0The main developer
> is coincidentally also very active as an OpenOCD developer, though as
> far as I know there is no OpenOCD (or even JTAG) support for the ZPU.
>
> > Right now the only thing between me and a good solution seems to be
> > connecting to available debug tools through JTAG and adding a new
> > processor to the tool. =A0Someone I know has done this for some of the
> > CM3 devices and I am trying to help him with the CM4 Kinetis parts.
> > Once that goal is reached I figure I'll have enough insight to adapt
> > the process to my FPGA processors.
>
> > I'm not looking to find a shortest path method adding a CPU to an
> > FPGA. =A0Those tend to be proprietary and large. =A0I am looking for op=
en
> > source all the way to give me enough control that I can optimize for
> > my needs.

I am very aware of the ZPU and the project is very active.  At least
the mailing list is very active.

That is one of my thoughts, to add JTAG support for the ZPU and other
open source FPGA CPUs. But the ZPU itself is not of great interest to
me.  The goal of the ZPU is not the same as my own.

Rick
0
Reply rickman 3/23/2011 9:42:36 PM

On Mar 20, 8:40=A0am, David Brown <david.br...@removethis.hesbynett.no>
wrote:
> On 20/03/11 06:06, rickman wrote:
>
> > On Mar 19, 6:21 pm, David Brown<david.br...@removethis.hesbynett.no>
> > wrote:
> >> On 19/03/11 22:25, Simon Clubley wrote:
>
> >>> On 2011-03-19, Simon Clubley<clubley@remove_me.eisner.decus.org-Earth=
..UFP> =A0 wrote:
>
> >>>> The JTAG adapter and driver are implemented within (and only within)
> >>>> OpenOCD.
>
> >>> That statement (with it's implied lack of _direct_ JTAG support withi=
n gdb
> >>> itself) is stronger than I can justify with my level of experience, s=
o let
> >>> me clarify: some parts of GDB may have direct support for specific JT=
AG
> >>> devices (even though I have not yet come across this support if it ex=
ists),
> >>> 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.
>
> >> Let me expand a little on that with some history of embedded gdb
> >> debugging before OpenOCD (and for non-ARM targets). =A0You probably kn=
ow
> >> much of this already, but perhaps by putting it in slightly different
> >> words it will help Rick (and maybe others) understand better. =A0I hop=
e 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. =A0The mainline version comes with several front-ends,
> >> several middle-ends, and several back-ends. =A0There are also specific
> >> ports or patched versions with additional variants of these ends. =A0O=
n
> >> 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. =A0For some uses, it is
> >> self-sufficient. =A0For other uses, it forms part of a chain of progra=
ms -
> >> which may even include more than gdb.
>
> >> At the front-end, you have the connection from the higher level world =
to
> >> gdb. =A0This 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). =A0There is also a graphics interface,
> >> Insight, that is often built into the gdb binary. =A0Or 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. =A0The 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 b=
e
> >> some specific commands).
>
> >> The middle-end supports the language and the target architecture. =A0g=
db
> >> supports C, C++, Ada, and various other languages. =A0And it supports =
a
> >> huge range of targets. =A0It is the middle-end that handles loading fi=
les,
> >> understanding debug symbols, registers, reading and writing memory, et=
c.
>
> >> The back-end also has a number of options. =A0It can connect to a nati=
ve
> >> process on suitable OS'es (such as for natively debugging programs
> >> running on Linux or Windows). =A0It can also connect using a serial po=
rt,
> >> pipe, or a tcp/ip socket and communicate with a lower-level debugger
> >> using the gdb debugging protocol. =A0This protocol is mostly, but not
> >> entirely, independent of the target architecture. =A0It is also someti=
mes
> >> build with target simulator backends.
>
> >> Mainline gdb by itself can therefore not debug embedded systems. =A0It
> >> knows nothing about jtag, BDM, or any other way of connecting to an
> >> embedded system. =A0The most common way to handle this is to have a pr=
oxy
> >> program that knows about the low-level interface, and which communicat=
es
> >> with gdb over a tcp/ip socket.
>
> >> It used to be common practice to make patched versions of gdb that
> >> directly support debugger interfaces. =A0For example, I have a gdb bui=
ld
> >> that communicate with a MC68332 using a parallel interface BDM debugge=
r.
> >> =A0 =A0Such patched monolithic builds made sense before, for speed rea=
sons -
> >> 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. =A0This is often t=
he
> >> case for debugging embedded Linux systems - here the "proxy" may in fa=
ct
> >> be a limited version of gdb running on the target. =A0But 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". =A0These are specific to the
> >> particular debugger interface, and let you use the same gdb for any
> >> supported debugger. =A0gdb talks to the sprite, and the sprite talks t=
o
> >> the hardware (via USB, typically). =A0The USB debugger interface then
> >> talks to the jtag interface on the target processor.
>
> >> Sometimes these proxy programs are not open source. =A0For example, TI=
 has
> >> not released information about jtag debugging for the msp430. =A0But i=
t
> >> was willing to release it under an NDA to some msp-gcc developers. =A0=
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 o=
n
> >> an "intelligent" debugger unit, such as the ZY1000 debugger which
> >> connects to the host by Ethernet. =A0(The ZY1000 runs OpenOCD.).
>
> >> So where does OpenOCD fit into this picture? =A0OpenOCD is a debugger
> >> proxy program (it does other things as well). =A0It 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. =A0The idea is to hav=
e
> >> 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 interface=
s.
> >> =A0 =A0Many of these interfaces are very simple - it is common to use =
the
> >> FTDI2232 chips for JTAG interfaces, which blindly pass data between th=
e
> >> USB and the JTAG connection. =A0Others 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.
>
> > David, thank you for an excellent explanation. =A0This makes it all muc=
h
> > more clear now. =A0It 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. =A0So it should not be a large job to make any
> > of the open source tools compatible with it.
>
> That's possibly correct - but remember that "open source" doesn't
> necessarily mean "documented", "well-written" or "understandable". =A0Man=
y
> developers who publish their source are proud of their work, and want
> people to view their code and think it is well written, and also want to
> write code that other people can work with an contribute to. =A0But that
> doesn't apply to all open source code, especially if it has been written
> as an internal project and then later released without due care and
> planning. =A0I have no idea what the situation is for Freescale's code
> here - I am just saying that even if the code is available, it does not
> mean the OpenOCD developers can trivially support the interface.
>
> > So I guess the only thing I am still not clear on is exactly what the
> > protocol levels are on the target side. =A0It seems clear that there is
> > a protocol between GDB and OpenOCD. =A0There are many protocols between
>
> Yes, that is GBD's protocol. =A0It is documented in the gdb documentation=
,
> if you are interested in the details:
>
> <http://sourceware.org/gdb/current/onlinedocs/gdb/>
> <http://sourceware.org/gdb/current/onlinedocs/gdb/Remote-Protocol.html...=
>
>
> > OpenOCD and the various JTAG adapters. =A0But a given adapter can work
> > with multiple targets. =A0At the JTAG point it is just a way to get
> > commands into the target. =A0What level of this hierarchy has to
> > understand the debugging protocol of the target? =A0I guess it would be
> > OpenOCD, yes? =A0Where is this documented? =A0In particular, for the
>
> Yes, it is OpenOCD that handles this - though possibly in cooperation
> with "intelligent" debugger hardware interfaces. =A0For simple interfaces
> such as the FTDI-based devices, OpenOCD handles all the translation
> between gdb protocol telegrams (such as "read 4 bytes from address
> 0x1234") into the required jtag telegrams for the particular target.
>
> > Kinetis devices could that be figured out from the OSJTAG code? =A0Or
> > does that just dumbly handle JTAG commands like the FTDI device? =A0If
> > not there, where would this info be available from?
>
> I don't know whether the OSJTAG does any work itself, or passes things
> on directly. =A0But either way, one would hope there is enough
> documentation available to allow OpenOCD to speak to the OSJTAG - if
> not, then reverse engineering based on the source code for OSJTAG is
> certainly possible.

The source for the OSJTAG device that's on the Kinetis boards is made
available by P&E Micro, so you can actually check what it's doing (and
alter it, if it weren't passing things through as cleanly as one
desired).  If you grab the "Design Documents" link from the link
below, you'll have the source both for the libusb drivers and for the
OSJTAG/OSBDM JM60 firmware that runs on the embedded debugger:
http://www.pemicro.com/osbdm/index.cfm

I've been experimenting with the API provided by P&E and so far I've
had trouble with the abstracted functions that aren't just providing
fairly direct JTAG access (as far as I can tell, the commands for
halting and resetting are silently failing (returns OK status), but
reading from memory on the Kinetis gives me an error... not sure if
I'm missing something).  They provide an alternate command structure
through a "special function" interface, look at
"jtag_kinetis.c:t_special_feature" which appears to be a more direct
JTAG interface, which as far as I can tell is what most of the
existing working IDEs and programming tools are using to flash and
program the device.  Unfortunately I'm not that familiar with the
internals of ARM's JTAG implementation, but I suspect maybe this
interface could be somehow mated up with OpenOCD, or in the worst case
the firmware on the debugger chip could be altered as desired to
provide the interface needed and that could be used in stead.

> > Maybe I should say that I am trying to figure out how someone might
> > add debugging support to a tool. =A0I think OpenOCD would be used, so I
> > guess we just need to make OSJTAG work with OpenOCD which would be a
> > win/win.

Originally I was hoping that I might be able to put together a simple
flashing interface for this device that wouldn't need a full JTAG
implementation behind it, but what I've been finding, I think that
OpenOCD may be a better bet for communicating with this device and
getting both debugging and flashing functionality working.

>
> Yes, that's about right.
>
> Of course, there is another possible route. =A0The Kinetis development
> cards have a standard ARM jtag port, as far as I can see, in addition to
> the OSJTAG USB device. =A0So you can use any other Cortex-compatible
> debugger with them - ranging from powerful "intelligent" devices like
> the ZY1000 to cheap (or even home-made) FTDI-based devices. =A0So while I
> hope that OSJTAG support will make its way into OpenOCD sometime (and if
> Freescale are on the ball, they will contribute to that work
> themselves), you can always get around it with some cheap and simple
> hardware.

0
Reply James 3/25/2011 6:52:34 PM

On Mar 25, 2:52=A0pm, James Snyder <jbsny...@gmail.com> wrote:
> On Mar 20, 8:40=A0am, David Brown <david.br...@removethis.hesbynett.no>
> wrote:
>
> > On 20/03/11 06:06, rickman wrote:
> > > OpenOCD and the various JTAG adapters. =A0But a given adapter can wor=
k
> > > with multiple targets. =A0At the JTAG point it is just a way to get
> > > commands into the target. =A0What level of this hierarchy has to
> > > understand the debugging protocol of the target? =A0I guess it would =
be
> > > OpenOCD, yes? =A0Where is this documented? =A0In particular, for the
> > > Kinetis devices could that be figured out from the OSJTAG code? =A0Or
> > > does that just dumbly handle JTAG commands like the FTDI device? =A0I=
f
> > > not there, where would this info be available from?
>
> > I don't know whether the OSJTAG does any work itself, or passes things
> > on directly. =A0But either way, one would hope there is enough
> > documentation available to allow OpenOCD to speak to the OSJTAG - if
> > not, then reverse engineering based on the source code for OSJTAG is
> > certainly possible.
>
> The source for the OSJTAG device that's on the Kinetis boards is made
> available by P&E Micro, so you can actually check what it's doing (and
> alter it, if it weren't passing things through as cleanly as one
> desired). =A0If you grab the "Design Documents" link from the link
> below, you'll have the source both for the libusb drivers and for the
> OSJTAG/OSBDM JM60 firmware that runs on the embedded debugger:http://www.=
pemicro.com/osbdm/index.cfm

Yes, I have the source.  It just occurred to me, what is required to
compile the source?  Do you need the Freescale tools or are there open
source tools for that?  Likely I will be looking at using different
hardware anyway, so this may not be an important issue.


> I've been experimenting with the API provided by P&E and so far I've
> had trouble with the abstracted functions that aren't just providing
> fairly direct JTAG access (as far as I can tell, the commands for
> halting and resetting are silently failing (returns OK status), but
> reading from memory on the Kinetis gives me an error... not sure if
> I'm missing something). =A0They provide an alternate command structure
> through a "special function" interface, look at
> "jtag_kinetis.c:t_special_feature" which appears to be a more direct
> JTAG interface, which as far as I can tell is what most of the
> existing working IDEs and programming tools are using to flash and
> program the device. =A0Unfortunately I'm not that familiar with the
> internals of ARM's JTAG implementation, but I suspect maybe this
> interface could be somehow mated up with OpenOCD, or in the worst case
> the firmware on the debugger chip could be altered as desired to
> provide the interface needed and that could be used in stead.

I assume you are doing all this by reverse engineering the code rather
than finding any docs?


> > > Maybe I should say that I am trying to figure out how someone might
> > > add debugging support to a tool. =A0I think OpenOCD would be used, so=
 I
> > > guess we just need to make OSJTAG work with OpenOCD which would be a
> > > win/win.
>
> Originally I was hoping that I might be able to put together a simple
> flashing interface for this device that wouldn't need a full JTAG
> implementation behind it, but what I've been finding, I think that
> OpenOCD may be a better bet for communicating with this device and
> getting both debugging and flashing functionality working.

Does OpenOCD communicate with the Kinetis devices?  I thought not.  Or
by "device" do you mean the OSJTAG chip?


> > Yes, that's about right.
>
> > Of course, there is another possible route. =A0The Kinetis development
> > cards have a standard ARM jtag port, as far as I can see, in addition t=
o
> > the OSJTAG USB device. =A0So you can use any other Cortex-compatible
> > debugger with them - ranging from powerful "intelligent" devices like
> > the ZY1000 to cheap (or even home-made) FTDI-based devices. =A0So while=
 I
> > hope that OSJTAG support will make its way into OpenOCD sometime (and i=
f
> > Freescale are on the ball, they will contribute to that work
> > themselves), you can always get around it with some cheap and simple
> > hardware.

I have longer term goals in mind.  In addition to working with the
Kinetis devices, I want to learn as much as practical about the
debugging hardware and software so that I can provide support for
other devices.

Rick
0
Reply rickman 3/26/2011 2:33:07 PM

On Mar 26, 9:33=A0am, rickman <gnu...@gmail.com> wrote:
> On Mar 25, 2:52=A0pm, James Snyder <jbsny...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Mar 20, 8:40=A0am, David Brown <david.br...@removethis.hesbynett.no>
> > wrote:
>
> > > On 20/03/11 06:06, rickman wrote:
> > > > OpenOCD and the various JTAG adapters. =A0But a given adapter can w=
ork
> > > > with multiple targets. =A0At the JTAG point it is just a way to get
> > > > commands into the target. =A0What level of this hierarchy has to
> > > > understand the debugging protocol of the target? =A0I guess it woul=
d be
> > > > OpenOCD, yes? =A0Where is this documented? =A0In particular, for th=
e
> > > > Kinetis devices could that be figured out from the OSJTAG code? =A0=
Or
> > > > does that just dumbly handle JTAG commands like the FTDI device? =
=A0If
> > > > not there, where would this info be available from?
>
> > > I don't know whether the OSJTAG does any work itself, or passes thing=
s
> > > on directly. =A0But either way, one would hope there is enough
> > > documentation available to allow OpenOCD to speak to the OSJTAG - if
> > > not, then reverse engineering based on the source code for OSJTAG is
> > > certainly possible.
>
> > The source for the OSJTAG device that's on the Kinetis boards is made
> > available by P&E Micro, so you can actually check what it's doing (and
> > alter it, if it weren't passing things through as cleanly as one
> > desired). =A0If you grab the "Design Documents" link from the link
> > below, you'll have the source both for the libusb drivers and for the
> > OSJTAG/OSBDM JM60 firmware that runs on the embedded debugger:http://ww=
w.pemicro.com/osbdm/index.cfm
>
> Yes, I have the source. =A0It just occurred to me, what is required to
> compile the source? =A0Do you need the Freescale tools or are there open
> source tools for that? =A0Likely I will be looking at using different
> hardware anyway, so this may not be an important issue.

I'm not actually sure.  It looks like SDCC supports the 68HC08, so
that may work?
http://sdcc.sourceforge.net/
The debugger chip on the K60 tower board is an MC9S08JM60, so
regardless presumably one needs a working compiler for this in order
to create a new firmware.

>
> > I've been experimenting with the API provided by P&E and so far I've
> > had trouble with the abstracted functions that aren't just providing
> > fairly direct JTAG access (as far as I can tell, the commands for
> > halting and resetting are silently failing (returns OK status), but
> > reading from memory on the Kinetis gives me an error... not sure if
> > I'm missing something). =A0They provide an alternate command structure
> > through a "special function" interface, look at
> > "jtag_kinetis.c:t_special_feature" which appears to be a more direct
> > JTAG interface, which as far as I can tell is what most of the
> > existing working IDEs and programming tools are using to flash and
> > program the device. =A0Unfortunately I'm not that familiar with the
> > internals of ARM's JTAG implementation, but I suspect maybe this
> > interface could be somehow mated up with OpenOCD, or in the worst case
> > the firmware on the debugger chip could be altered as desired to
> > provide the interface needed and that could be used in stead.
>
> I assume you are doing all this by reverse engineering the code rather
> than finding any docs?

Yep, pretty much.  There are no docs on this and I'm not sure if
they'll be publishing anything to indicate how their interface works
besides the minimal comments that exist.

>
> > > > Maybe I should say that I am trying to figure out how someone might
> > > > add debugging support to a tool. =A0I think OpenOCD would be used, =
so I
> > > > guess we just need to make OSJTAG work with OpenOCD which would be =
a
> > > > win/win.
>
> > Originally I was hoping that I might be able to put together a simple
> > flashing interface for this device that wouldn't need a full JTAG
> > implementation behind it, but what I've been finding, I think that
> > OpenOCD may be a better bet for communicating with this device and
> > getting both debugging and flashing functionality working.
>
> Does OpenOCD communicate with the Kinetis devices? =A0I thought not. =A0O=
r
> by "device" do you mean the OSJTAG chip?

I'm not sure that OpenOCD has been updated to be aware of the Kinetis
devices, but I suspect this isn't an overly complicated process.  I
was meaning that in terms of getting mileage out of the OSJTAG chip
with open source tools patching/updating OpenOCD is probably the
quickest/easiest path to getting something useful where one could
debug/flash a Kinetis over the OSJTAG using open tools.

I suspect that it wouldn't be too hard to get OpenOCD to work with it
using an existing supported interface and an appropriate adapter cable
to the 0.05" Samtec Cortex Debug connector that exists onboard.

>
> > > Yes, that's about right.
>
> > > Of course, there is another possible route. =A0The Kinetis developmen=
t
> > > cards have a standard ARM jtag port, as far as I can see, in addition=
 to
> > > the OSJTAG USB device. =A0So you can use any other Cortex-compatible
> > > debugger with them - ranging from powerful "intelligent" devices like
> > > the ZY1000 to cheap (or even home-made) FTDI-based devices. =A0So whi=
le I
> > > hope that OSJTAG support will make its way into OpenOCD sometime (and=
 if
> > > Freescale are on the ball, they will contribute to that work
> > > themselves), you can always get around it with some cheap and simple
> > > hardware.
>
> I have longer term goals in mind. =A0In addition to working with the
> Kinetis devices, I want to learn as much as practical about the
> debugging hardware and software so that I can provide support for
> other devices.

Fair enough.  This situation has certainly piqued my interest in
knowing a bit about the details of the JTAG implementation. :-)

>
> Rick

0
Reply James 3/28/2011 7:51:12 PM
comp.arch.embedded 19743 articles. 3 followers. Post

36 Replies
1152 Views

Similar Articles

[PageSpeed] 10


  • Permalink
  • submit to reddit
  • Email
  • Follow


Reply:

Similar Artilces:

Freescale's Idea of Open Source JTAG
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...

[News] Open Source Entrepreneurship Forum, Health Commons Adopting Open Source Ideas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Open source explained ,----[ Quote ] | The Open Source Entrepreneurship Forum in Hyderabad last Saturday was a | unique event that targeted people who ran or planned to start companies in | the open source software (OSS) space. Organized by the Twincling Society for | Open Source, the annual event aims to provide entrepreneurs insights into the | open source model and help with the right selection of licensing, marketing | and resources while building a company. `---- http://www.livemint.com/2008/05/26235305/Open-source-explained.html ...

[News] SourceForge Starts Open Source Contest; Open Source Software Comes to SOA; Open Source Content is Like a Baby
Open Source Community Honors Its Best and Brightest ,----[ Quote ] | The second annual SourceForge.net Community Choice Awards build on the | resounding community interest and success of the inaugural awards. `---- http://money.cnn.com/news/newsfeeds/articles/marketwire/0275543.htm Bringing Open Source to SOAs ,----[ Quote ] | Although large commercial vendors made early strides into the market for SOA | software, open-source components are rapidly finding their way into the | picture. | | Vendors such as Iona Technologies, Red Hat, MuleSource, WSO2, Sun | Microsystems and even IB...

[News] Open Source Gains Momentum, Stanford Opens Open Source Lab
Open source on campus: The Stanford Open Source Lab ,----[ Quote ] | Over the last few months, open source has gained momentum at Stanford | University in the form of the Stanford Open Source Lab. Inspired by groups | like the Free Software Foundation, Oregon State University’s Open Source Lab, | Drupal, Openflows Community Technology Lab, and MIT’s Open Course Ware, a few | people at Stanford decided to band together and dedicate their time and | energies to the development of free/open/libre learning and knowledge | resources. `---- http://www.redhatmagazine.com/2008/02/12/open...

[News] PacktPub Rewards Open Source Projects, Sun Opens Open Source Portal
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 PacktPub 2008 Awards - Most Promising Open Source Web CMS ,----[ Quote ] | Every great web CMS contest showcases winners in much anticipated categories, | frequently highlighting names everyone already knows. But what about the new | guy on the block? PacktPub.com is proud to announce the 2008 Most Promising | CMS winners. `---- http://www.cmswire.com/cms/web-cms/packtpub-2008-awards-most-promising-open-source-web-cms-003432.php OSUM portal from Sun ,----[ Quote ] | Yes, that acronym is pronounced “Awesome.” Cheesy acronyms aside, the Op...

I Hate Open Source Software
Here is a great article on why Open Source software sucks. http://www.grumpynerd.com/?p=132 Some tidbits: "Linux Sucks That�s right I just called out the crown jewel of the open source movement. Linux is great if you�re building a super-computing cluster, you run a web hosting company with 3,000 servers or you�re Facebook/Yahoo/Google and you need something very custom and very rare. Linux is pretty nice if you�re deploying an embedded system application. But for the 99.7% of us that are using computers for common everyday tasks Linux is a wholesale disaster. On the server...

Open Source CEO: Open Source model is broken
BusinessWeek.com, December 2008 Open Source: The Model Is Broken The open-source business model that relies solely on support and service revenue streams is failing to meet the expectations of investors By Stuart Cohen SPECIAL REPORT CEO Guide to Open-Source Software For anyone who hasn't been paying attention to the software industry lately, I have some bad news. The open-source business model is broken. Companies have long hoped to make money from this freely available software by charging customers for support and add-on features. Some have succeeded. Many others have failed or will ...

[News] Open Source Fabrics and Open Source Fabrication
Apparel export to India: Exporters want open source of raw goods ,----[ Quote ] | Country's readymade garment exporters yesterday sought 'open source' | of textile fabrics and sweater yarns to export six million pieces of | apparel items to India on preferential tariff rate. `---- http://nation.ittefaq.com/artman/publish/article_34455.shtml 3-D Fabrication Goes Open Source ,----[ Quote ] | Undoubtedly, the main attraction of the system is that it is open | source, meaning that anyone can enhance and improve the system for | the benefit of all users. This is in stark contrast to...

[News] Open Source Development and Open Source Frauds
Open source is a development model ,----[ Quote ] | "As a development model the GPL and other licenses offer the | possibility of more rapidly creating network effects around software. | Linux has extraordinary network effects. Open source can create a | community of developers and users who in turn create features that | make software more sustainable... `---- http://blogs.zdnet.com/open-source/?p=875 I have been seeing the following for a while (dozens of press releases) and thought the same thing as BTL. Intalio makes disingenuous claim that it has released code as open source ,-...

[News] Open Source Database Contributes to Open Source IDE
Ingres Announces New Developer Bundle for Eclipse Users ,----[ Quote ] | Ingres Corporation announced the availability of a new Ingres | Eclipse Bundle for Java developers worldwide. The new bundle | contains all of the components needed to successfully build | and deploy next-generation applications with Eclipse, a popular | open source development framework, on Ingres 2006, Ingres's | latest release of its open source database. `---- http://opensourceblog.itproportal.com/?p=276 ...

[News] More on the Index for Open Source Players and Open Source Fakers
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Customers versus users: a distinction ,----[ Quote ] | He is of course right that most enterprise adopters would not care about an | openness index, and in fact such a thing could actually cause more harm than | good by confusing potential adopters. However enterprises were not the | potential audience that I (or I believe MTG) envisioned for what MTG called | the Equitable Open Source label. `---- http://blogs.the451group.com/opensource/2008/05/21/customers-versus-users-a-distinction/ Here are some brand-new example of very weak 'o...

Open-source JTAG software?
Does anyone know of any open-source software which will program an XCF04S (Xilinx serial PROM) on JTAG? It also needs to issue a CONFIG command to start configuration. Thanks - Evan Evan Lavelle schrieb: > Does anyone know of any open-source software which will program an > XCF04S (Xilinx serial PROM) on JTAG? It also needs to issue a CONFIG > command to start configuration. JDrive should do the job: http://direct.xilinx.com/bvdocs/appnotes/xapp500.pdf You can also check what algorithms openwince supports: http://openwince.sourceforge.net/jtag/ Kolja Sulimma On Wed, 16 Aug 2006...

Is open sourcing a good idea?
Hi all, I've recently finished a working draft of my game engine (my first)! Looking at it now, since it's so big and I was the only coder on it, it feels like 9 parts hack and 1 part good design. I've heard a lot of support for the notion of open sourcing large projects and for web sites like sourceforge.net. While I'm quite certain that I've not written anything "new" or "groundbreaking", I'm hesitant to open source my engine or even to share it online. It feels too much like just throwing away all my hard work. At the same time though...

[News] Open-source Intelligence and Open Source Mashup Server
Open secret: spy agencies reject essential sources ,----[ Quote ] | Many intelligence officers still do not have access to the internet, they | say, and the six intelligence agencies still do not have a functioning | electronic system for sharing information. | | The information revolution has given the agencies access to masses of "open | source" intelligence, especially on the internet. `---- http://www.theage.com.au/news/national/open-secret-spies-snub-prime-source/2008/03/01/1204227055173.html New Open Source WSO2 Mashup Server ,----[ Quote ] | WSO2, the global open so...

[News] Fake Open Source versus Real Open Source
When open source projects close the process, something's wrong ,----[ Quote ] | Twice in recent weeks open source projects have surprised me with their lack | of openness. In both cases, developers acted or spoke out in such a way as to | intentionally push other developers away from their work. | | [...] | | The root of both problems is an unwillingness to commit to a truly open | development process. `---- http://www.linux.com/feature/120635 Sounds like some certain "Free" project from Canonical. More on that soon. Related: Using open source as a marketing ploy ,...

An open source analogy: Open source is like sharing a recipe
<http://www.linuxtoday.com/it_management/an-open-source-analogy-open-source-is-like-sharing-a-recipe.html> <quote> Imagine you've baked something for your friends—a loaf of bread, perhaps. By sharing this bread with your friends, you've given them something that not only sustains them, but also strengthens your relationship with them. Certainly, these are valuable gifts. But what if you share more than the finshed product? Suppose that in addition to the loaf of bread, you also give your friends the recipe for that bread. Now you've given them something even...

Open Source Conference in Japan: Open Source Realize Forum 2005
more info at: http://www.oreillynet.com/pub/wlg/6599 (includes a link to the home page (in Japanese) and a google translation of it) The odd think is that I didn't see anything about Ruby. :( -- thanks, -pate ------------------------- ParseTree is a little brown stinky ferret that digs down a hole and violently rips the AST away from the warm bosom of ruby. In other words, we cheat, they don't. Hello, pat eyler <pat.eyler@gmail.com> wrote: > more info at: > http://www.oreillynet.com/pub/wlg/6599 > (includes a link to the home page (in Japanese) and a google trans...

[News] Open Source and BMC Talk About "Open Source"
Open source @ Intel: Dirk Hohndel speaks ,----[ Quote ] | "Intel contributed to many of the very early free software projects like gcc | and glibc, and of course has been an active contributor to the Linux kernel | for many years. I don't think we actually know which project was the first." `---- http://blogs.cnet.com/8301-13505_1-9754202-16.html William Hurley: Managing In The Open ,----[ Quote ] | Color BMC not surprised. Last week we launched our BMC Developer Network to | open our community to the world. This week we launched an additional customer | council for custo...

Need repository/open-source suggestions for open-source Scheme release.
[This posting did not make into comp.lang.scheme the first time I tried it, or at least it hasn't so far, so I am reposting. My apologies for abuse of bandwidth of it ends up showing up twice.] Today I released version 2.23 of Wraith Scheme. Wraith Scheme 2.23 is a shareware and open-source full R5 Scheme implementation for the Apple Macintosh, with enhancements for parallel processing, by which I mean multiple copies of the Wraith Scheme application (separate Unix processes) all running at once, sharing Scheme main memory. Wraith Scheme 2.23 is a full 64-bit Macintosh application, tha...

[News] A Shift in Mindset from Open Source to Free Libre Open Source
Does Open Source Licensing Matter? ,----[ Quote ] | While the title of the panel was "Why Open Source Licensing Matters," panel | moderator Matt Asay, vice president of business development at Alfresco, said | it does matter, though maybe not for all the people on this panel. Asay | recently helped to move Alfresco from a SugarCRM-type attribution license to | the GPLv2. | | Though the panel didn't agree on the value of OSI-approved open source | licensing, it did agree on the value of the open source model. | | "Open source as a community matters," Asay ...

Need repository/open-source suggestions for open-source Scheme release.
I am the developer of Wraith Scheme, an R5 version that runs on the Macintosh. I am close to releasing a 64-bit version of Wraith Scheme, to run on Intel Macintoshes under Snow Leopard. I am leaning toward releasing source for it under the GNU general public license. I have never released an open-source project before, or worked on one, and could use some advice, particularly on what to do about a public source code repository. I am not even quite sure what questions I should be asking. I have no present plans to start an open-source development project for Wraith Scheme myself, so I don&...

[News] Trend Micro Praise Open Source, Go Open Source
Trend Micro CTO hints that Trend will Open Source Code ,----[ Quote ] | In a stunning revelation in Trend Micro: Open source is more secure, | Trend CTO Raimund Genes hints that Trend may release their code as | an open source project! `---- http://blogs.technet.com/security/archive/2006/06/14/435960.aspx ...

[News] Open Source-hostile Companies Bet Business on Open Source
Yahoo sets program to boost distributed computing ,----[ Quote ] | Yahoo has been a main supporter of Hadoop, an open source distributed file | system that lets users process massive amounts of data. The company said it | would make Hadoop available to academic research in a supercomputing-class | data center. `---- http://www.reuters.com/article/technologyNews/idUSWNAS201020071112?feedType=RSS&feedName=technologyNews http://tinyurl.com/39o5qm 127 million Oracle shares vote for open source at annual shareholders meeting ,----[ Quote ] | While seemingly a lot, 127 million shares d...

[News] The Importance of Open Source Interoperability; Open Source Wins Award
Can Technology Be Made To Play Nice Together? Really? ,----[ Quote ] | Customers today have proprietary software and they have open source software. | Customers just want it all to work together. This dream is becoming a reality | as companies and projects in both the commercial and open source space are | working together to solve the interoperability challenge and bring a solution | to one of the biggest pain points for customers today. `---- http://www.sda-india.com/sda_india/psecom,id,25,site_layout,sdaindia,articles,587,p,0.html We need one standard, not 'translators'. ...

CERN developes open source hardware and open source hardware license
CERN developes open source hardware and open source hardware license -------------------------------------------------------------------- http://arstechnica.com/open-source/news/2011/07/for-the-good-of-all-of-us-cern-launches-open-source-hardware-effort.ars Open source hardware repository http://www.ohwr.org/ Huge range of open source electronics projects http://www.ohwr.org/projects/ Lots and lots of goodies!!!!! Wishbone - a bus for adding peripherals written in VHDL/Verilog) Wishbone crossbar ARMadillo - A multi-purpose ARM-based small piggy-back PCB with Linux support, ...