Seeking JTAG emulator for Atmel AT91 ARM Cores on Linux

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: snipped-for-privacy@netfront.net ---

Reply to
Johnson
Loading thread data ...

The excellent Rowley CrossWorks ARM tools are available for Linux, and support several JTAG interfaces, including their own.

Reply to
Leon

That sounds great. I will check into it right now.

How about Zylin Embedded CDT?

formatting link

It > >> Hi there,

--- news://freenews.netfront.net/ - complaints: snipped-for-privacy@netfront.net ---

Reply to
Johnson

Please tell me more about its advantages over the free tools, then I might buy. Thanks.

--- news://freenews.netfront.net/ - complaints: snipped-for-privacy@netfront.net ---

Reply to
Johnson

on

or

Excellent support, a superb IDE, their own libraries, etc. Download it and try it.

Reply to
Leon

OpenOCD with a $50 FT2232 USBJTAG adapter worked fine with the SAM9 parts when I tried it, but I never had a need to actually use it in anger.

formatting link
formatting link

[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? For 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. It 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.).

Never tried it.

If money was no object, I'd go for the Zylin Z1000.

formatting link

Abatron's BDI3000 is also nice but it doesn't talk GDB's remote protocol directly the way the Z1000 does. With the BDI3000 you've got 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.

--
Grant
Reply to
Grant Edwards

Why do you need JTAG to debug the firmware at all? Besides using printf for debugging, you can use gdbserver on your platform (if you have a spare serial port or over TCP/IP) and e.g. Insight on your development machine, if you are not comfortable with gdb (but Insight is a bit buggy, so most of the time I use the raw gdb command line interface, when using a debugger, which I don't need very often).

I've used this even for Linux kernel and driver level debugging for an AT91 system, but usually debugging this level is better with GPIO test signals, a scope and some syslogs.

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

For the debugger hardware, also look at Zylin:

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.

Reply to
David Brown

Good point and than you for your reply.

We designed our own board, JTAG and USB ports are in the board, No Serial Port or Ethernet. I am going to run GDB server on the board, and use GDB for debugging. The USB has to be connected to a peripheral during the debug process, so basically only JTAG is available for debugging, which is the main reason that I am asking around about the possibility to debug the firmware with JTAG.

Do you have any idea for my trouble? Thanks a lot.

Frank Buss wrote:

--- news://freenews.netfront.net/ - complaints: snipped-for-privacy@netfront.net ---

Reply to
Johnson

This looks pretty much tha same situation I was in.

If you run JTAG via OpenOCD, it can serve as a GDB server, so there is no need to have the server on target board.

I used Amontec USB dongle for JTAG and OpenOCD for ARM7TDMI (AT91R40008).

--
Tauno Voipio
tauno voipio (at) iki fi
 Click to see the full signature
Reply to
Tauno Voipio

I would use at least two test points for a serial connection, if you don't need all IO pins for your application. And even then maybe you should design in some 0 ohm resistors to use the serial port and disconnect the application side. When I helped developing the software for a similar platform, it was very useful to see the u-boot output, setting environment variables in u-boot over the serial port and watching the kernel messages after linux booted. But maybe there is a way for all this with JTAG, too.

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

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.

Gee, I thought that if money were no object, you'd go for a Lauterbach!

--
Best Regards
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

IMO, a big mistake. Access to the debug UART is immensly useful. All you need to put on the board is a three-pin header (tx, rx, gnd). Logic level to RS232 level can be handled in a adapter.

Why do you say "only JTAG is available for debugging?" If you're running gdb-server on the target, you can connect to it via Ethernet.

--
Grant Edwards               grant.b.edwards        Yow! I threw up on my
                                  at               window!
 Click to see the full signature
Reply to
Grant Edwards

Can such a setup be used to debug user-space application code?

--
Grant Edwards               grant.b.edwards        Yow! Hey, waiter!  I want
                                  at               a NEW SHIRT and a PONY TAIL
 Click to see the full signature
Reply to
Grant Edwards

Sure, if I had a core with a trace interface (which I don't).

--
Grant Edwards               grant.b.edwards        Yow! I want to mail a
                                  at               bronzed artichoke to
 Click to see the full signature
Reply to
Grant Edwards

I guess that it will be difficult. My application was stand-alone code.

The JTAG debug connection is for desperate situations. It understands hardware addresses, and with an enabled MMU, addressing can get challenging for the debugger.

If you can run a kernel on the target, gdbserver and network connection is the way to go.

--
Tauno Voipio
tauno voipio (at) iki fi
 Click to see the full signature
Reply to
Tauno Voipio

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.

I certainly need to debug user-space application code, and I understand it is far from easy. If I tried not to use multi-threading in my application code, do you think it will make debug with JTAG + OpenOCD easier?

BTW, is there any links/Application Notes for debugging with JTAG + OpenOCD?

Reply to
Johnson

l

Yow! I threw up on my

=A0 =A0 =A0 =A0 =A0 =A0 =A0 window!

=A0 =A0 =A0 =A0 =A0

Sorry no ethernet provided.

Reply to
Johnson

:

Basides of the two link that Grant Ed. provided at the top, I want more application notes and links.

Reply to
Johnson

l

Yow! I threw up on my

=A0 =A0 =A0 =A0 =A0 =A0 =A0 window!

=A0 =A0 =A0 =A0 =A0

If it is a mistake, I got to fix it. Is it a good idea for the USB firmware to generate one more virtual port for debugging (with GDB server)? The other virtual port will still be reserved for the peripheral.

Reply to
Johnson

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.