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 19732 articles. 2 followers. Post

36 Replies
1119 Views

Similar Articles

[PageSpeed] 44


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

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

Open Sourcing can be a good idea.
Ok, I've seen a bunch of stuff about how open-source can suck, and a bunch of religeous wars and it's been rather hard to try to follow the thread, so I thought I'd toss out something a little positive, here. First: managing an open-source project can be a real pain. Look at SourceForge and what percentage of projects ever make it past the "thinking about it" stage -- very very few. Managing a group of remote volunteers who have ideas about how to make your pet project better is a very complicated task. It's not impossible, but not everyone is up t...

[News] More Funding for Open Source, Finance Ideas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Appcelerator raises $2.1M to build apps on multiple devices ,----[ Quote ] | Appcelerator, the maker of an open source | platform for building desktop and smartphone | applications, has raised $2.1 million in new | funding. `---- http://mobile.venturebeat.com/2010/06/11/appcelerator-raises-2-1m-to-build-apps-on-multiple-devices/ Consona Corporation Acquires Open-Source and Cloud ERP Software Provider Compiere Inc. http://www.prweb.com/releases/Consona_Corporation/Compiere/prweb4151854.htm How to Make Money on Open Source ...

is the open sourcing of IntelliJ IDEA getting some love?
Hi, news has been out since 15 days but my Google-groups-fu is weak so I can't find a link talking about it in c.l.j.p. IntelliJ IDEA 9 is open source and the first preview is already accessible... Sending love to JetBrains, Alex alexandre_paterson@yahoo.fr wrote: > news has been out since 15 days but my Google-groups-fu > is weak so I can't find a link talking about it in c.l.j.p. > > IntelliJ IDEA 9 is open source and the first preview is already > accessible... Note that it is Community Edition that is open source. Check: http://www.jetbrains.com/idea/n...

opinion of my open source function wiki idea?
I have started a project that I have always felt would be very interesting. It has been going very slowly until recently when my company pitched in some money to help it along. This forum seems like a great place to get some feedback! I really appreciate any comments you might have. The idea is to create an open-source web-based tool that will allow users to contribute functions to and in so doing, extend the overall functionality of the tool. The idea started as a project similar to something like this: http://ponce.sdsu.edu/online_calc.php where you build little math functions that users can...

Microsoft Steals Open Source Ideas For Security
Proof that Microsoft's "inovations" are nothing more than stolen ideas. Tangible evidence that Open Source development will continue to produce superior programs for years to come. By J. Eric Smith Nov 18 2003 .. .. Although its latest product, Windows Server 2003, has a much better security record, Microsoft has had little success shaking the image of being lax on security. Gates's plan to address this gives us a peek at what we're going to find in Windows XP Service Pack 2, and the plan is nothing if not comprehensive: .. .. * At the top of the list is ...

[News] Linux and Open Source Gift Ideas
The Open source gift guide - Open source hardware, software and more for the holidays ,----[ Quote ] | There are hundreds of gift guides this holiday season filled with junk | you can buy - but a lot of time you actually don't own it, you can't | improve upon it, you can't share it or make it better, you certainly | can't post the plans, schematics and source code either. `---- http://www.makezine.com/blog/archive/2006/11/the_open_source_1.html Related: Give the Gift of Pre-Installed Linux This Year ,----[ Quote ] | With Christmas around the corner, you'll be glad to ...

[News] Open Source Facilitates Choice, Innovative Ideas
With 'open innovation,' no idea is left behind ,----[ Quote ] | Companies used to think of product development in terms of a sieve: | Lots of ideas were thrown in and most got filtered out along the way, | with a few eventually becoming shippable goods. | | [...] | | The result, proponents say, is a model of "open innovation" in which | good ideas are not lost simply because they don't fit with the company| | that developed them. `---- http://news.com.com/With+open+innovation%2C+no+idea+is+left+behind/2100-1014_3-6096783.html ...

[News] Report: Open Source Compete on Ideas and Execution
Report advocates open-source approach for software acquisition ,----[ Quote ] | The report also noted that the use of open-source software would | make "industry more likely to compete on ideas and execution versus | product lock-in." `---- http://www.gcn.com/online/vol1_no1/41415-1.html begin oe_protect.scr Roy Schestowitz <newsgroups@schestowitz.com> espoused: > Report advocates open-source approach for software acquisition > > ,----[ Quote ] >| The report also noted that the use of open-source software would >| make "industry more l...

[News] Open Source Ideas and GNU/Linux at Their Core
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Four More Offbeat Open Source Ideas ,----[ Quote ] | If you prefer your media devices hackable (as ThinkGeek puts it), check out | the $179.99 Neuros OSD media recorder and player. It runs Linux, and all of | its firmware is open source. You connect the OSD to your TV and give it an | analog video input and it can encode video in various formats, including | formats for the PSP or mobile phones. You can find out more at the Neuros | site. `---- http://ostatic.com/176105-blog/four-more-offbeat-open-source-ideas Recent: Credit crunch ...

[News] First American Honoured Open Source Ideas?
The first [open source] American ,----[ Quote ] | Franklin was truly ahead of his time. He wasn't just the first American, | he was the first open source American. | | Freedom. Transparency. Collaboration. Accountability. Sound familiar? | This was how he lived his life and impacted society. `---- http://www.redhat.com/magazine/021jul06/features/ben_franklin/ "Roy Schestowitz" <newsgroups@schestowitz.com> wrote in message news:1663808.kF3O0gRkot@schestowitz.com... > The first [open source] American > > ,----[ Quote ] > | Franklin was truly ahead of...

New(?) idea for free open source software development
Hi! I'm a 32 years old novice to average programmer, and I have an idea which I believe to be fairly good: An authentification system to replace the old fashion password authentification method. The general idea is that a user - using the computer mouse - draws his/her signature onto a canvas on the login screen. The login program records, from millisecond to millisecond, the mouse motions and the curve drawn on the canvas by the user. Then the program compares the curve with an already stored pattern which has been preadapted to match the authentic users graphical mouse signatu...

Presenting a new(?) idea for free open source software development.
Hi! I'm a 32 years old novice to average programmer, and I have an idea which I believe to be fairly good: An authentification system to replace the old fashion password authentification method. The general idea is that a user - using the computer mouse - draws his/her signature onto a canvas on the login screen. The login program records, from millisecond to millisecond, the mouse motions and the curve drawn on the canvas by the user. Then the program compares the curve with an already stored pattern which has been preadapted to match the authentic users graphical mouse signature. I bel...

Open source Xilinx JTAG programmer with Digilent USB support
I've written a Xilinx JTAG programmer. It runs on Win32 and Linux Following cables are supported: Parallel III Digilent USB (on Linux it needs libusb, Win32 needs the original driver from digilent, utilizes full USB transfer speed!) Following chips are implemented: Spartan-3 Family XCF Family Virtex-II Pro family If it seems people are interested I'll clean up the code and put it up on sourceforge.net. The most interesting part is the Digilent USB driver. It could be used in other applications too :) fpgakid@gmail.com wrote: > I've written a Xilinx JTAG programmer. It run...

[News] Open Source Startup Join Forces, Share Ideas
Open-Source Startups Speak Out in Germany ,----[ Quote ] | Their message was loud and clear: Open source is a disruptive | technology that is here to stay, and it will nibble, or maybe | even someday gobble, away at the customer base of big and priceyc | ommercial software companies. `---- http://www.cio.com/blog_view.html?CID=26538 ...

Presenting a new(?) idea for free open source software development.
Hi! I'm a 32 years old novice to average programmer, and I have an idea which I believe to be fairly good: An authentification system to replace the old fashion password authentification method. The general idea is that a user - using the computer mouse - draws his/her signature onto a canvas on the login screen. The login program records, from millisecond to millisecond, the mouse motions and the curve drawn on the canvas by the user. Then the program compares the curve with an already stored pattern which has been preadapted to match the authentic users graphical mouse signature. I bel...

Open source Xilinx JTAG Programmer released on sourceforge.net
Hi All, I've released the first version of my Xilinx JTAG programmer for Win32/Linux. Supports Parallel III Cable and Digilent USB. Check and of message for supported devices! http://sourceforge.net/projects/xilprg This is a very first version, so please be patient with me and provide as much info as possible if you report a bug! Zoltan zoltan_csizmadia at yahoo dot com Supported operations: --------------------- Detect device chain: detect Erase device: erase pos E.g.: erase 1 Program device: program [-bit|-bin|-mcs] pos file E.g.: program 1 c:\untitled.mcs ...

Call for Ideas/Developers: Qanah Open Source Enterprise eCommerce
[I realized after I sent this that "Announce" in the subject might be construed as an as advertisement, thus would have been discarded. My apologies for the duplicate post. I also made a few edits.] Hello all! Intro and "Credentials" My name is Joshua Kugler, and I currently a system administrator for the University of Alaska Fairbanks Center for Distance Education <http://www.distance.uaf.edu/>, and am currently pursuing my Masters in Computer Science. I've used Perl for years, writing entire database driven web sites using it <see http://asuaf.org&...

[News] Open Source Ideas Draw Attention from Many Directions
OurSpace: Resisting the Corporate Control of Culture ,----[ Quote ] | Finally, her argument for the third strategy examines a "free culture" | movement inspired by open source software, using innovations in artistic | licensing through Creative Commons, a project housed in Stanford, as an | example. `---- http://www.portlandmercury.com/portland/Content?oid=394634&category=22148 Related: Mom Sues Universal Music for DMCA Abuse ,----[ Quote ] | The Electronic Frontier Foundation (EFF) filed suit today against Universal | Music Publishing Group (UMPG), asking a federal ...

Presenting a new(?) idea for free open source software development.
Hi! I'm a 32 years old novice to average programmer, and I have an idea which I believe to be fairly good: An authentification system to replace the old fashion password authentification method. The general idea is that a user - using the computer mouse - draws his/her signature onto a canvas on the login screen. The login program records, from millisecond to millisecond, the mouse motions and the curve drawn on the canvas by the user. Then the program compares the curve with an already stored pattern which has been preadapted to match the authentic users graphical mouse signature. I bel...

Open Source Bridge Call for Proposals: We welcome your ideas (until March 31)
We are happy to announce that the Open Source Bridge Call for Proposals is now open! We would love to hear all of those interesting ideas you have in your head�and so would everyone else. That�s why we will be accepting your proposals for Open Source Bridge talks through March 31. What kind of proposals, you ask? Open Source Bridge strives to be a different kind of open source conference. We�re not focusing on specific languages, platforms, or pursuits. We�re focusing on what it means to be a responsible open source citizen. As such, we�ve worked to craft categories that allow people to shar...

How to get started on my idea? Need free/open source level design program.
Hi guys. I have an idea for a ultra realistic combat game but I want to do some basic things like put together a level and experiment with models and things. A VERY long time ago, there was a little program I used on the Amstrad CPC 464 called "Adventure game creator" which let you input certain things and it would sort the underlying code out for you. Is there anything similar on modern DirectX/Open GL PCs? I've heard of something called Dark Basic but I really don't have much money to spend on software, I can't believe the prices of some software eit...