> 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.
Reply by David Brown●August 21, 20102010-08-21
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?
>
Reply by David Brown●August 21, 20102010-08-21
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!
Reply by Johnson●August 20, 20102010-08-20
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.
Reply by Grant Edwards●August 20, 20102010-08-20
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
Reply by George Neuner●August 20, 20102010-08-20
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
Reply by Johnson●August 20, 20102010-08-20
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=
=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?
Reply by David Brown●August 20, 20102010-08-20
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?
>
Reply by Grant Edwards●August 20, 20102010-08-20
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!!
Reply by David Brown●August 20, 20102010-08-20
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.