Freescale's Idea of Open Source JTAG

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

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.

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.

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

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

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

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

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

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

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