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