Seeking JTAG emulator for Atmel AT91 ARM Cores on Linux

Yes, getting yourself something akin to a console serial port over the USB sounds like a very, very good idea. And not just for GDB.

Assuming you have a USB host interface, can't you just put a hub in there and plug in a usb-serial adapter next to the application peripheral? Drivers should already be in the kernel source, you might only need to enable them in the build config.

If you have a USB device interface you may need to look into something like the USB composite device so as to present both your application interface and something like a USB serial. Then you controlling computer (or something emulating/proxying for it) can either run GDB or pass the channel of to your debug machine over a serial port or ethernet or something.

Next time hook up those uart pins, even if just to pads you can solder to.

Sounds great. Thanks!

I write my linux userspace embedded code such that it will compile for a desktop linux pc (or sometimes even for windows) using a combination of ifdefs and build configurations to incorporate either real hardware interface functions or dummy/simulated ones depending on the target. Then I do my initial debugging natively on the development machine, and only push the code out to the target when I think it has a fair chance of working or really needs the real hardware. This is particularly good for user interface issues since you can prototype ideas and show them around, let potential customers play with the product, etc without having to have built any hardware yet. Writing code that builds for multiple targets also means we can change embedded architectures relatively easily.

With an ethernet interface I also set up scripts in my development environment that can FTP a new copy of the userspace code into the target, kill any running copy, and then launch the new one either standalone or under gdbserver. This works really well with a compressed root filesystem image that gets turned into a ramdisk on boot - I can play around with a running system all I want, then once I get a batch of changes done I do a full build of the application and system image containing it and only then reflash the target.

Thanks for sharing!

Do you have any recommendation for the USB composite device? I prefer simple and easy solutions. Thanks.

The usb composite device is a driver in the linux kernel that lets a device side interface be multiple functions at once, for example pseudo ethernet and also mass storage.

Is your embedded board a usb host or a usb device?

If its a host, you d> > > > >

The usb composite device is a driver in the linux kernel that lets a device side interface be multiple functions at once, for example pseudo ethernet and also mass storage Is your embedded board a usb host or a usb device? If its a host, you dont need the composite driver, you just need a hub and a usb serial dongle and to build and load the appropriate kerne module for the dongle (plug it into a linux desktop instead and use dmesg and lsmod to figure out what driver got autoloaded, then build and load that on your embedded system)

A warning: I think it will be very difficult to use JTAG, only. If you use u-boot, you'll need some kind of interactive communication for setting up the Linux boot parameters etc. and to see the debug output of u-boot and the linux boot process. Maybe this is possible with JTAG, too, and in theory you could setup anything before, including the u-boot environment, on your development host and then flash it with JTAG, but at least it is not the standard way and I think I would need much longer to get a board working with JTAG, only.

And if you are running Linux, usually you need some kind of shell access to setup init scripts, start daemons and applications for testing etc. Maybe you can setup a serial port over USB in Linux, but finding the right driver setttings for this USB support and watching the output, if a driver fails to load, is impossible without some interactive access in the beginning.

This would be like giving a braille instruction to a blind person for flying an airplane from New York to Cologne :-)

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

There is the ARM DCC that could possibly be used for this? Perhaps someone has put a facility for this into linux & u-boot already since it is a fairly standard debugger feature.

--

John Devereux

quoted text -

No, you don't have to use Zylin's plugin for CDT. Actually, I believe that plugin is a bit redundant these days since the standard Eclipse gdb support has better support for remote and non-native gdb.

The ZY1000 is an implementation of OpenOCD, which is an open source project for on-chip debugging for ARMs (and some support for MIPs and other devices). OpenOCD handles the low-level hardware, such as an FTDI chip connection often used on USB JTAG debuggers. Your gdb connects "remotely" to OpenOCD on a TCP/IP port. Thus anything that speaks "gdb protocol" will work with OpenOCD, and therefore the ZY1000. You can also connect to OpenOCD in other ways for doing low-level jtag access, chip programming, etc.

Others have mentioned that you can use an FTDI-based debugger with OpenOCD, which is absolutely correct. The only difference there is from a software viewpoint that OpenOCD runs on your PC, while with the ZY1000 it runs on the debugger hardware. The choice depends a lot on your budget and your needs - the ZY1000 is going to be significantly faster than an FTDI debugger, and it is connected by Ethernet. This makes it easy to access from different machines, independent of the host OS, and saves any time or effort in setting it up (getting a USB debugger to work with a mainstream modern Linux distro is seldom difficult, but if you have older distros it might be complicated. And getting OpenOCD to work properly with Windows can also be difficult).

Finally, I'd note that the Zylin developers are major contributors to OpenOCD - if you have issues with it, it's nice to be able to talk to people who know what they are doing. Some suppliers of USB JTAG debuggers may not have any experience with Linux or OpenOCD.

I'd also note that whatever you choose for your low-level debugging, other poster's suggestions about doing debugging and testing on a PC where possible is a good idea.

JTAG is useful for:

1) Troubleshooting hardware. 2) Debugging bootloader and kernel code.

I'd recommend using the bootloader for firmware download.

Atmel provides already-working bootloaders for their parts.

There's a simple one in masked ROM that's completely bullet-proof. The only way it won't run is if you do stuff that also breaks J-TAG. You can download to the one in Masked ROM via serial port or USB.

Atmel also provides U-Boot which knows how to do tftp (as a client) via Ethernet or various protocols via serial port. There are also multiple tftp server implementations for U-Boot, but due to unfathomable opposition by Hr. Denk, none of them are available in the official source tree.

JTAG is not useful for application debugging.

It's far from easy _if_you_use_JTAG_. It _is_ easy If you use the tools designed for the purpose.

No.

JTAG is not useful for debugging user-space application code runnon on Linux.

Running GDB-server on the target and gdb on the development host is how you do application debugging. That works even for multi-threaded programs.

--
Grant Edwards               grant.b.edwards        Yow! NEWARK has been
                                  at               REZONED!!  DES MOINES has
                              gmail.com            been REZONED!!

That's not /quite/ true. Most of the time with embedded Linux, jtag is only useful for board bring-up, bootloader debugging, and perhaps for kernel debugging. But occasionally it might be useful to stop everything and have the low-level access jtag conveniently gives you. You might find it easier to use jtag debugging if you want to view or change hardware registers, view memory, or other access low-level features of the system. It may be of interest to put the whole chip in "pause". You may also find it helpful when debugging interactions between user applications and kernel code.

But in general you are right - running gdb server on the target is normally far more useful, as are other debugging techniques (printf debugging, running the code on the host, etc.).

Yow! NEWARK has been

=A0 =A0 =A0 =A0 =A0 =A0 =A0 REZONED!! =A0DES MOINES has

=A0 =A0 =A0 =A0 =A0been REZONED!!

Hi Grant, thank you for your reply.

It seems that OpenOCD or Zylin ZY1000 JTAG Debugger can work together with the JTAG interface, to me it means JTAG can be the right tools for application debugging. What do you think?

Speaking as a pilot, that likely would not be terribly difficult if the plane has braille or talking instruments.

Almost anybody can _fly_ a plane (even a big jetliner) and most people can manage a successful (if not pretty looking) takeoff the first time ... what distinguishes a pilot is the ability to land.

George

Personally, I have my doubts as to how useful it is for kernel debugging except perhaps for the very initial startup-code where none of the perpherals are up and running. For things like debugging a device driver or some other kernel module I think printk and systemtap are going to be a lot more useful.

I've been looking into systemtap the past few days, and it's very cool. Unforunately there isn't yet ARM support for it's use on user-space code, and using it cross-platform takes some effort. But, it looks very powerfull for debugging things like device drivers and in-kernel protocol support.

Except it doesn't put the whole chip in "pause". It stops the CPU core from executing instructions. Peripherals like timers, UARTs, and Ethernet controllers keep running -- at least that's the behavior I've seen on other (non-Atmel) parts. IOW, when you do a halt via JTAG, the program state and CPU core are the only things that pause. Tx buffers in peripherals continue to drain, counters continue to overflow, Rx buffers in peripherals continue to overrun.

I'd try strace or systemtap first. :)

--
Grant Edwards               grant.b.edwards        Yow! Now we can become
                                  at               alcoholics!
                              gmail.com

8278 t

Hi Grant,

As for the emulator, do you have any that you want to recommend?

Thanks.

Contemporary Arm/Blackfin/Mips/Avr32 embedded systems sit at the juncture of two different approaches.

On the one hand, the last twenty years of small (8/16 bit) embedded mcu tool evolution has seen enhanced jtag hardware really displace serial ports, monitors, and flash programmers for most professional development usage. The tools tend to be cheap compared to a few days or even hours of wasted time and you can really get inside your system withiut having to design it for debugging. As vendors, engineers, and managers from that background move i.to larger systems they want to keep the same methodology. Without a kernel, and with a high enough jtag clock compared to flash size, this is workable.

But running embedded linux on these high powered mcus is taking a somewhat different approach. Instead of a chip on a board, its really the paradigm of developing for a headless server - a "real computer" you can log into and interact with at O/S level even as applications run (or die, relaunch, etc). A filesystem exists where you can save logs. And jtag is an arcane interface for most purposes, because it works below the level of operating system and memory management data structures on which application logic depends.

With most of these processors you have a choice - you can buy jtag hardware bundled with an ide to support bare metal development or development atop a lightweight proprietery kernel that the jtag software can unravel. Or you can run embedded linux, in which case your debug hardware consists of an ordinary serial, ethernet, or jtag cable which allows you to use "desktop-style" software debug tools and the average developer will have no need to purchase a jtag dongle unless trying to port the kernel to a new chip or make the kernel do new or indecent things.

Sorry, should be usb, not jtag as the third choice.

That's a bit like the myth that the Wright Brothers were the first people to make and fly a plane. They were in fact perhaps a dozen or more successful powered flights before them, in several different countries. But the Wright Brothers were the first to make a successful landing!