Freescale's Idea of Open Source JTAG

[...]

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?

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
Reply to
John Devereux
Loading thread data ...

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.

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

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.

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.

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.

Reply to
David Brown

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

Yes, it would be something like that.

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.

Reply to
David Brown

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:

formatting link

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
Reply to
Simon Clubley

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

Reply to
rickman

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.

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

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.

Reply to
David Brown

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

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.

/path/to/your/gdb

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

--

John Devereux
Reply to
John Devereux

to

e I

if

n

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.

e
t
y

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.

s
e
,

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

Reply to
rickman

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.

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.

Yes, that is my understanding.

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

Reply to
David Brown

e

Why on earth would you think he means anything different?

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

Reply to
rickman

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.

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

Reply to
David Brown

Code

=A0If

w
n
d

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.

e

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

Reply to
rickman

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.

You might be interested to look at the ZPU at . 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.

Reply to
David Brown

s
e

is

e
o
a

the

bly

h

en

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

Reply to
rickman

n gdb

o let

AG

ists),

ow

e I

n

).

ms -

to

,
e

db

a

les,

c.

ve

rt,

mes

oxy

es

ld

r.

sons -

he

ct

o

has

t

So

n

very

e

s.

the

e
h
y
,

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:

formatting link

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.

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.

Reply to
James Snyder

k

be

f

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 assume you are doing all this by reverse engineering the code rather than finding any docs?

I

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

o
I
f

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

Reply to
rickman

ork

d be

e

Or

=A0If

s

I'm not actually sure. It looks like SDCC supports the 68HC08, so that may work?

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

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.

so I

a
r

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.

t

to

le I

if

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

Reply to
James Snyder

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.