Eclipse ARM toolchain for the Linux

Eclipse finally got block selection in version 3.5 (Galileo).

You can toggle block selection mode with Alt+Shift+A.

Andy

Of course openocd itself can function as a "network based debug adaptor". I often run it on the lab laptop with a cheap jtag pod while talking to it from my main development machine.

I actually prefer this arrangement to my expensive abatron bdi2000, Openocd supports a wider range of devices and I can use the same cheap adapters and config files for board testing / production (done elsewhere).

The zy1000 should be more responsive though for debugging (and perhaps the company deserves support as contributors to the openocd project).

Interesting.

A Insight source kit ships a copy of gdb as part of the kit (for example, Insight 6.8 includes it's own version of gdb 6.8) and the Insight build procedure uses this included copy of gdb, ignoring any other version of gdb which might be available during building.

I looked to see if there was a way to point the Insight build routines to a standalone (and later) version of the gdb source kit, but I couldn't find a way to do this. Postings in the Insight or gdb mailing list from the authors also claimed that this was not possible, at which point I left it and started looking for another gdb front end.

If you have found a way to integrate a newer gdb kit into a Insight source kit, I would really appreciate knowing how you did it.

Thanks,

Simon.

I'd like to develop this theme of debug adapter pricing. At the far end of the scale, you have offerings from Abatron, which cost an astronomical 2000 ukp here in the uk. People like Wind River most likley have similar prices. Embest have the Unet-Ice, which has network and usb ports, at a reasonable 300-400 ukp ($400 in the US fwir), but only talks Angel debug protocol via the net. Then you have the usb only based boxes, with items like the J-Link, again at an astronomical 1000+ ukp in the uk, followed by the ulink 2 from Keil at around (iirc) 400.00 ukp, still pretty steep for a usb only adapter. Then you have the Chinese knockoffs of the Ulink and J-link at around 20-30 ukp via Ebay and the Silicon Labs adapter that comes with the si labs development kits. A replacement si labs adapter costs a mere 40 ukp.

There is a wide disparity in pricing and one has to ask questions like: If si labs can sell their adapter at 40 ukp, what is so special about the j-link that justifies a price tag of 1000+ ?. If you take the lid off, they all seem to have the same amount of hardware internally and similar build quality, so one can only assume that they charge as much as they think the market will stand. Same comparison with the abatron vs unetice at 2000 ukp vs 400 etc ad nauseum.

Network based debug is very useful if the target hardware is more than a couple of metres away and has the added advantage of isolation, which is essential for power electronics development, where a ground loop or spike can very easily zap the debug adapter. Yes, you can buy usb and jtag isolators, but have you seen the prices ?. The zylin box, while not cheap, is like a breath of fresh air in terms of competition, if it works as advertised. The more competition, the better.

Norway. Don't know if you are familiar with labf.com?. Have used their nfs client for windows (NfsAxe) for years, since around v2 and it just works out of the box. Just 40 euros per license as well. I think the hummingbird nfs client was around 500 ukp at the time I was originally looking, so no prizes for guessing which was used. Some good stuff comes from the cold North :-)...

Regards,

Chris

Apologies, you are correct. Just checked the insight build directory and there is a subdir labelled gdb !, so it looks like it's included as part of insight download. I wonder what would happen if you create a new gdb subdir, untgz a different version and run configure ?. The interesting question would be, what's changed to prevent this working ?.

It was August 2008 and I do remember having to go back quite a way with gcc and binutils to get a clean build under Solaris.

Gnu software used to be so easy to build. Now you almost need a degree in osf makefiles to do anything non standard...

Regards,

Chris

I wasn't following the gdb developers list at the time but my _guess_ is that maybe they didn't (remove functionality when they removed the Angel stuff from the source tree). Obscure features/protocols often end up in a broken state as other parts of the system evolve. If there's nobody with the knowlege/desire/hardware/time to maintain the obscure features, they end up being removed after they've been sitting in a non-working, non-maintained state for a few years.

In other cases, an obscure feature (that may be working) is removed because the maintainers know it's going to be broken by a big refactoring or redesign, and nobody steps ups to bring the obscure feature forward with the rest of the system.

Or maybe they just got tired of the ugliness. :)

I don't know if there are other debuggers out there that still talk the Angel protocol, but Embest (and their customers) might be well-served by either implimenting the standard GDB remote protocol or providing a daemon that translates between "GDB remote" and whatever they do speak.

There are several differences in the way these debug boxes work, that can influence their price and their worth (though I agree that the two concepts don't always correlate well).

The cheapo debuggers are typically made from an FTDI2232 device and a couple of level converters. These work fairly well, and it's easy to integrate them into your own boards. There is good OpenOCD support for a whole range of combinations of pinning on these devices. But they are not very fast for downloads (which makes a difference for bigger projects), and they have significant latency when the communication is two-way. For example, handling breakpoints requires quite a number of messages back and forth between the processor and the host, with each bus turnaround taking several milliseconds.

Then there are medium-complexity debuggers which use USB but have a dedicated microcontroller (or programmable logic) to handle the low-level communication - these greatly reduce the latency for many operations. These are more fussy about the debuggers they will talk to

- there may or may not be OpenOCD and/or gdb support.

Then you have the high-end devices which again have a local microcontroller, and which use Ethernet to communicate with the host. These have much higher download speeds, and the low-level communication has low latency. They vary a lot as to which debuggers they support - typically, they will work with big-name commercial toolchains. Some will also support gdb directly - Abatron do on their more expensive devices (but not on the cheaper ones).

Some devices have trace support - that adds a lot to the cost, but may be useful. Some devices support debugging on a variety of architectures, though you often have to pay significantly for "processor adaptors" of some sort.

Sometimes the price makes sense, sometimes it does not. I have in the past had parallel port debuggers consisting of a few logic chips and costing over a thousand dollars - without software.

The ZY1000 is cheaper than most networked debuggers, and implements OpenOCD on the board. It talks OpenOCD and gdb protocols (and a few other protocols I think, but you'd have to check for details).

I don't know labf - but then, I haven't looked for an NFS client for windows.

It's not /that/ cold here (at least, not normally - the past two winters were unusually cold). I live in the south west, and in the summer it's warm enough to swim in the sea, get sunburned, etc. I've even been swimming in the sea north of the Arctic Cirle, under the midnight sun, with snow on the tops of the hills over the fjord (and I don't mean Finnish style break-the-ice-first swimming - I mean picnic on the beach, dry yourself in the sun swimming).

This sound pretty good, as you could even use a pocket pc with network and usb to provide a very compact solution. Could you give a few more details of what software lives at each end and hints / pointers on where to find info on configuration ?. Can do some legwork to get it going, but have no in depth knowledge of gdb internals at all. Could be a good spare time project.

I already looked into network based usb hubs, (Belkin, Keyspan etc) but for at least for Keil ulink and the Si labs adapters, neither work at debug level. You can see the remote usb device attached at the host end, but the ide can't see it all. I guess they must be bypassing some or all of the usb stack, or even poking the hardware directly. Might be a config issue, but neither company seemed particularly interested in providing help to resolve the issue, nor were forthcoming in terms of any explanation...

Regards,

Chris

Embest don't tell you that the adapter runs angel, but I was curious about the protocol used and was looking for a way to use the adapter from Sol 10 / Gdb. The embest toolchain and ide runs on windows and is gnu based, but has what looks like a knockoff, or perhaps custom licensed Keil like ide. I just ran wireshark on the network and then found that you can telnet into the box, where all was revealed.

I don't know if any other adapters still run angel, but how easy would it be to do the work to get it back into the build ?. This is coming from someone who knows nothing about gdb internals, its configuration etc, but it might be a good spare time project, given enough background info...

Regards,

Chris

I don't know. It's been 10 years since I mucked about inside gdb. If the gdb internal APIs have changed significantly, getting the RDI target stuff back in may involve a lot of work

If you asked on the gdb developer mailing list, somebody would probably be able explain why it was removed and what it would take to put it back in.

It might actually be easier to write a daemon that translates between the gdb remote protocol and ADP (Angel Debugging Protocol). There are several reasons why that might be a better approach:

The main drawbacks to a translator daemon is the increased command/response latency may have an adverse impact on performance when doing things like handling breakpoints on-the-fly.

A third choice would be to add ADP support to OpenOCD.

I wouldn't mind the pricing of Abatron, Ronetix et al. if it weren't for the fact that even though they're advertised as being multi-protocol you have to pay separately for every family. Last time I found a price list for one of these devices, the additional family licenses were something like 50% of the initial cost.

-a

Hi Chris, sure, I have no knowlege of gdb internals either!

Laptop ======

In my case the laptop has a "Amontec jtag-key" connected to it, with its drivers. There are probably dozens of other even cheaper jtag pods you can use these days.

On the laptop I have openocd installed. A command line like

openocd -f interface/jtag-key.cfg -f target/lpc2478.cfg -f pcb.cfg

...starts up the openocd daemon.

The file pcb.cfg contains some commands specific to my hardware, for many single-chip micro targets you may not need it. There is extensive documentation in the openocd manual and an active mailing list. The openocd project web site is .

From then on everything can be done from the main "desktop" machine.

Desktop =======

There I have a gnu arm toolchain including arm-elf-insight. Normally for local debugging I would have a .gdbinit file including a line

target remote locahost:3333

This is the usual way to tell gdb to talk to a local debug agent, e.g. a locally running openocd. This is simply changed to point to the IP address of the laptop e.g.

target remote 192.168.1.123:3333

Then gdb talks to the remote copy of openocd running on the laptop. Openocd acts just like e.g. an Abatron at the same address, i.e. it speaks the gdb remote debug protocol. You can use insight to program flash, single step etc as usual.

I use linux on both ends of the link, but it is basically the same for windows once you have installed your toolchain and/or openocd + jtag adapter drivers. In fact I use the same openocd configuration for a windows laptop that is used externally for board test and firmware programming.

Installation / Config =====================

For windows Freddie Chopin has made available some openocd binaries .

For linux you can compile from source. I made a local git mirror and compile from that.

For the arm toolchain I use my own script to fetch+compile but the summon-arm-toolchain one looks good too. For insight I used the latest one I could find here:

This is still behind the latest gdb so I might have a go at building it myself, substituting the latest gdb as discussed here just now. Anyone tried that?

I tried that but it failed. I don't remember if it failed during the configure or the make, but I had already decided I was probably going to have to go looking for another front end at that point, so I only made a couple of attempts at making it work.

:-)

Although all my Internet facing machines are running current versions of Linux, I have some older boxes which are not Internet connected and run older versions of Linux, even back to RH9, as they still do the job just fine.

Installing newer software on those boxes soon reveals which pieces of software have been tested against something other than a Linux distribution released in the last 6 months.

Simon.

And if you are a hobbyist and want to use something even cheaper than that with a suitable ARM board, there's also the parallel port based Wiggler clones. :-)

(Assuming of course you still have hardware with a real parallel port.)

The Olimex one (so far) works a lot better for me than I expected.

Simon.

Yes, but with the GDB 7.1 kit and the released Insight 6.8 kit.

That combination failed, but I don't remember why and I only made a couple of attempts (as I had already decided that I was probably going to have to look for another front end) so I don't know if it was a basic incompatibility issue or a integration issue on my part.

Simon.

So openocd is effectively standalone, input debug data at one side and usb jtag or at the target hw side. Assuming a Linux / unix box,the daemon listens directly on a port, or gets called by inetd, depending on the system ?.

What i'm trying to do is build a model of how all the bits fit together in terms of data flow between modules, but if the above or similar is the case, it fills in a lot of the gaps.

Thanks for all that. One neat solution might be a s/hand netbook running Linux, with built in usb and net, even wireless, then use one of the lower cost usb solutions to talk to the target. Try it on an old laptop first of course, but might be fun to build for other targets, even older stuff like Sun lx, just to be perverse :-).

Have printed this out, to go to file. Again, thanks...

Regards,

Chris

Interesting -- in C (and presumably C++), but not makefiles.

That's right. Never tried it via inetd, I just manually start it. I have various configurations anyway for different boards/processors, so I have to tell openocd what it is talking to by using the correct command line to it. (You can also run a script from the command line to e.g. erase and program flash, when using just to flash firmware. You don't need the toolchain for that.)

That's it AFAIK.

Absolutely, go for it! I have an old eeepc 701 that should work fine for that, it's already running debian.

Here are my notes for building openocd on debian:

Compiling OpenOCD for Linux ===========================

Debian Prerequisites:

automake libftdi-dev libusb-dev git libtool make

Purge any existing installation (debian one seems to override source-compiled one)

aptitude purge openocd

If don't have existing copy,

git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd

Else just

cd openocd git pull

To update it.

cd openocd ./bootstrap git submodule init git submodule update ./configure --enable-maintainer-mode --enable-ft2232_libftdi --enable-parport

--enable-parport_ppdev --enable-amtjtagaccel --disable-shared make sudo make install

(Actually I don't think the "submodule" lines above are needed any more)