Forums

Seeking JTAG emulator for Atmel AT91 ARM Cores on Linux

Started by Johnson August 18, 2010
On 19/08/2010 23:15, Johnson wrote:
> On Aug 19, 1:41 am, David Brown<da...@westcontrol.removethisbit.com> > wrote: >> On 19/08/2010 00:22, Johnson wrote: >> >>> That sounds great. I will check into it right now. >> >>> How about Zylin Embedded CDT?http://www.zylin.com/embeddedcdt.html >> >>> It integrates into Eclipse. >> >> For the debugger hardware, also look at Zylin: >> <http://www.zylin.com/zy1000.html> >> >> Disclaimer - I know this company because they are located near us. I >> haven't used the device myself, but it certainly looks to me like it >> will do the job you need, and you can be confident that it will play >> well with Eclipse CDT, and both Linux and Windows hosts. >> >> >> >>> Leon wrote: >>>> On 18 Aug, 21:29, Johnson<gpsab...@yahoo.com> wrote: >>>>> Hi there, >> >>>>> We are porting a windows application from desktop into embedded Linux on >>>>> Atmel AT91 ARM Cores, thus we need JTAG to debug the firmware under a >>>>> Linux environment. However, SAM-ICE only connects via USB to a PC >>>>> running Microsoft Windows2000 or XP. So I am looking for a JTAG emulator >>>>> running on Linux. If you have any good idea/knowledge, could you >>>>> please help? >> >>>>> BTW, a friend of mine recommended YAGARTO toolchain for JTAG under >>>>> Linux, is it the best solution so far? >> >>>>> Thanks. >> >>>>> Johnson >> >>>>> --- news://freenews.netfront.net/ - complaints: n...@netfront.net --- >> >>>> The excellent Rowley CrossWorks ARM tools are available for Linux, and >>>> support several JTAG interfaces, including their own. >> >>> --- news://freenews.netfront.net/ - complaints: n...@netfront.net ---- Hide quoted text - >> >> - Show quoted text - > > Well, it seems that if I only have JTAG and I want to denug the user- > space applications, Zylin ZY1000 JTAG Debugger is my only choice for > now. Any other opionion or advice? > > To use ZY1000, I will also need Zylin Embedded CDT, right? >
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.
On 2010-08-19, Johnson <gpsabove@yahoo.com> wrote:

> Thank you very much for sharing the knowledge! It is really my dream > to use JTAG plus OpenOCD for all purpose: firmware download, boot load > debugging, and application debugging.
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.
> I certainly need to debug user-space application code, and I > understand it is far from easy.
It's far from easy _if_you_use_JTAG_. It _is_ easy If you use the tools designed for the purpose.
> If I tried not to use multi-threading in my application code, do you > think it will make debug with JTAG + OpenOCD easier?
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.
> BTW, is there any links/Application Notes for debugging with JTAG + > OpenOCD?
-- Grant Edwards grant.b.edwards Yow! NEWARK has been at REZONED!! DES MOINES has gmail.com been REZONED!!
On 20/08/2010 16:09, Grant Edwards wrote:
> On 2010-08-19, Johnson<gpsabove@yahoo.com> wrote: > >> Thank you very much for sharing the knowledge! It is really my dream >> to use JTAG plus OpenOCD for all purpose: firmware download, boot load >> debugging, and application debugging. > > 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. > >> I certainly need to debug user-space application code, and I >> understand it is far from easy. > > It's far from easy _if_you_use_JTAG_. It _is_ easy If you use the > tools designed for the purpose. > >> If I tried not to use multi-threading in my application code, do you >> think it will make debug with JTAG + OpenOCD easier? > > No. > > JTAG is not useful for debugging user-space application code runnon on > Linux. >
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.).
> 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. > >> BTW, is there any links/Application Notes for debugging with JTAG + >> OpenOCD? >
On Aug 20, 8:09=A0am, Grant Edwards <inva...@invalid.invalid> wrote:
> On 2010-08-19, Johnson <gpsab...@yahoo.com> wrote: > > > Thank you very much for sharing the knowledge! It is really my dream > > to use JTAG plus OpenOCD for all purpose: firmware download, boot load > > debugging, and application debugging. > > JTAG is useful for: > > =A0 1) Troubleshooting hardware. > > =A0 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. =A0There 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. > > > I certainly need to debug user-space application code, and I > > understand it is far from easy. > > It's far from easy _if_you_use_JTAG_. =A0It _is_ easy If you use the > tools designed for the purpose. > > > If I tried not to use multi-threading in my application code, do you > > think it will make debug with JTAG + OpenOCD easier? > > 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. =A0That works even for multi-threaded > programs. > > > BTW, is there any links/Application Notes for debugging with JTAG + > > OpenOCD? > > -- > Grant Edwards =A0 =A0 =A0 =A0 =A0 =A0 =A0 grant.b.edwards =A0 =A0 =A0 =A0=
Yow! NEWARK has been
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 REZONED!! =A0DES MOINES has
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 gmail.com =A0=
=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?
On Fri, 20 Aug 2010 06:05:26 +0200, Frank Buss <fb@frank-buss.de>
wrote:

>This would be like giving a braille instruction to a blind person for >flying an airplane from New York to Cologne :-)
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
On 2010-08-20, David Brown <david@westcontrol.removethisbit.com> wrote:

>>> If I tried not to use multi-threading in my application code, do you >>> think it will make debug with JTAG + OpenOCD easier? >> >> No. >> >> JTAG is not useful for debugging user-space application code runnon >> on Linux. > > 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.
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.
> 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".
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.
> You may also find it helpful when debugging interactions between user > applications and kernel code.
I'd try strace or systemtap first. :)
> 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.). > >> 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. >> >>> BTW, is there any links/Application Notes for debugging with JTAG + >>> OpenOCD?
-- Grant Edwards grant.b.edwards Yow! Now we can become at alcoholics! gmail.com
On Aug 19, 12:38=A0pm, Ulf Samuelsson <u...@invalid.atmel.com> wrote:
> Grant Edwards skrev 2010-08-19 05:43: > > > On 2010-08-18, Johnson<gpsab...@yahoo.com> =A0wrote: > > >> We are porting a windows application from desktop into embedded Linux > >> on Atmel AT91 ARM Cores, thus we need JTAG to debug the firmware > >> under a Linux environment. However, SAM-ICE only connects via USB to > >> a PC running Microsoft Windows2000 or XP. So I am looking for a JTAG > >> emulator running on Linux. If you have any good idea/knowledge, could > >> you please help? > > > OpenOCD with a $50 FT2232 USB<->JTAG adapter worked fine with the SAM9 > > parts when I tried it, but I never had a need to actually use it in > > anger. > > I would say that a good emulator would be useful when you debug > the kernel. You can often develop an application on a Linux PC, > and then port it to the ARM. > This will give you native gdb/insight or whatever. > > Debugging an application is a pain, when dynamic libraries are used. > > > > > > > > > =A0 =A0http://openocd.berlios.de/web/ > > =A0 =A0http://www.sparkfun.com/commerce/product_info.php?products_id=3D=
8278
> > > [I've never tried the SAM-ICE -- I don't really "do" Windows.] > > > You do know that while a JTAG adapter may be useful for > > troubleshooting hardware and debugging the bootloader or Linux startup > > code, it's pretty much useless for debugging applications? =A0For > > debugging applications, you run gdb-server on the target and gdb on > > your development host. > > > If you're using an Atmel SAM9 part, then I'd be surprised if you > > really need to do hard-core debugging of a bootloader or Linux startup > > code, since U-Boot and Linux are already ported and pretty much "just > > work". > > > [I don't know as much about the SAM7 parts running Linux.] > > > FWIW, I did all my hardware troubleshooting and board bring-up using > > the bootloader code that's in the AT91SAM9 masked ROM. =A0It implements > > commands to read/write memory (and therefore registers), and lets you > > load small test programs into SRAM and run them. > > > The protocol spoken by the ROM bootloader is trivial [it's documented > > in the part's user's manual], and I wrote a small Python program to > > send it various commands (read/write registers, etc.). > > >> BTW, a friend of mine recommended YAGARTO toolchain for JTAG under > >> Linux, is it the best solution so far? > > > Never tried it. > > > If money was no object, I'd go for the Zylin Z1000. > > > =A0 =A0http://www.zylin.com/zy1000.html > > Gee, I thought that if money were no object, you'd go for a Lauterbach! > > > > > Abatron's BDI3000 is also nice but it doesn't talk GDB's remote > > protocol directly the way the Z1000 does. =A0With the BDI3000 you've go=
t
> > to run a daemon to translate between BDI's protocol and GDB's > > protocol. > > > But, I couldn't really justify spending that kind of cash when the > > Atmel ROM bootloader code did everything I needed to do to bring up > > boards. > > -- > Best Regards > Ulf Samuelsson > These are my own personal opinions, which may > or may not be shared by my employer Atmel Nordic AB- Hide quoted text - > > - Show quoted text -
Hi Grant, As for the emulator, do you have any that you want to recommend? Thanks.
George Neuner wrote:
> On Fri, 20 Aug 2010 06:05:26 +0200, Frank Buss <fb@frank-buss.de> > wrote: > >> This would be like giving a braille instruction to a blind person for >> flying an airplane from New York to Cologne :-) > > 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. >
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!
Grant Edwards wrote:
> On 2010-08-20, David Brown <david@westcontrol.removethisbit.com> wrote: > >>>> If I tried not to use multi-threading in my application code, do you >>>> think it will make debug with JTAG + OpenOCD easier? >>> No. >>> >>> JTAG is not useful for debugging user-space application code runnon >>> on Linux. >> 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. > > 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. > >> 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". > > 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 haven't done much work with ARMs, so I'll take your word for it here. On the chip I've been using recently (a MPC5554 with a PPC core), you choose for each peripheral if they are to stop or continue when you are in debug mode, which is very useful.
>> You may also find it helpful when debugging interactions between user >> applications and kernel code. > > I'd try strace or systemtap first. :) > >> 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.). >> >>> 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. >>> >>>> BTW, is there any links/Application Notes for debugging with JTAG + >>>> OpenOCD? >
Johnson wrote:
> On Aug 20, 8:09 am, Grant Edwards <inva...@invalid.invalid> wrote: >> On 2010-08-19, Johnson <gpsab...@yahoo.com> wrote: >> >>> Thank you very much for sharing the knowledge! It is really my dream >>> to use JTAG plus OpenOCD for all purpose: firmware download, boot load >>> debugging, and application debugging. >> 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. >> >>> I certainly need to debug user-space application code, and I >>> understand it is far from easy. >> It's far from easy _if_you_use_JTAG_. It _is_ easy If you use the >> tools designed for the purpose. >> >>> If I tried not to use multi-threading in my application code, do you >>> think it will make debug with JTAG + OpenOCD easier? >> 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. >> >>> BTW, is there any links/Application Notes for debugging with JTAG + >>> OpenOCD? >> -- >> Grant Edwards grant.b.edwards Yow! NEWARK has been >> at REZONED!! DES MOINES has >> gmail.com been 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? >
As has already been said here, JTAG is not really very useful for application debugging - its for the low-level stuff. The point of the ZY1000 is that when you are doing JTAG debugging or downloading, it is faster and often easier to connect than most other JTAG tools. But it is not normally much use in application debugging - JTAG is too intrusive for that. The fundamental issue is that a tool that works by starting and stopping the entire processor is not well suited to a system that is doing lots of things at once.