JTAG debuggers - a couple of questions

Hi Group

Having exclusively worked with ICE emulators in the past, I have some
(probably  dumb) questions with regard to JTAG debuggers.

Could someone explain to me how target support is done with JTAG
debuggers?

I see (cheap) products which merly consist of a cable/dongle and
interestingly such products do not talk much (if at all) about
supporting specific targets. On the other hand the more enhanced ones
explcitly list targets supported and in most cases have an impressive
price tag attached to every given target.

This raises the question if the native support available inside the
debugger software (i.e. GDB) contains everything needed for these more
simple devices?

So far I see that more advanced products are aparently much faster
when it comes to downloading and probably also are not sluggish while
single stepping etc. What other advantages do the more expensive
products have?

I don't mind spending money for a good product, but I obviousely would
prefer to understand why/what for :-)

TIA

Markus

On 2005-09-27, Markus Zingg <m.zingg@nct.ch> wrote:
> Hi Group
>
> Having exclusively worked with ICE emulators in the past, I have some
> (probably  dumb) questions with regard to JTAG debuggers.
>
> Could someone explain to me how target support is done with JTAG
> debuggers?

Didn't we just do this discussion last week?  

And then again earlier today?

> I see (cheap) products which merly consist of a cable/dongle
> and interestingly such products do not talk much (if at all)
> about supporting specific targets.

Some of those rely on SW to do the actual JTAG protocol, as
well as the target-specific control and register addressing
stuff. They're horribly, horribly slow (e.g. downloads take a
half hour instead of a few seconds).

> On the other hand the more enhanced ones explcitly list
> targets supported and in most cases have an impressive price
> tag attached to every given target.

Those do the JTAG stuff in hardware and contain a uController
that translates the target-specific control and register
addressing stuff into a more "standard" protocol -- though that
protocol is often specific to the inteface's product line.

The best units (IMO) impliment an open protocol such as the GDB
remote protocol.

> This raises the question if the native support available
> inside the debugger software (i.e. GDB) contains everything
> needed for these more simple devices?

I think there are GDB "drivers" for a few of the low-end units.
Other units require you to run a translator process that
translates from the vendor-protocol to GDB remote protocol.

Others require you to use the debugger from the same vendor.

> So far I see that more advanced products are aparently much
> faster when it comes to downloading and probably also are not
> sluggish while single stepping etc. What other advantages do
> the more expensive products have?

Some of them provide flash-programming modes, built-in low
level debuggers you can operate via telnet, network interfacing
so you can debug from the other side of the planet, etc.

> I don't mind spending money for a good product, but I
> obviousely would prefer to understand why/what for :-)

-- 
Grant Edwards                   grante             Yow!  With this weapon
                                  at               I can expose fictional
                               visi.com            characters and bring about
                                                   sweeping reforms!!

Hi Grant

Thanks for your reply. 

>> Having exclusively worked with ICE emulators in the past, I have some
>> (probably  dumb) questions with regard to JTAG debuggers.
>>
>> Could someone explain to me how target support is done with JTAG
>> debuggers?
>
>Didn't we just do this discussion last week?  
>
>And then again earlier today?

Sorry - no ofense - but no. The other thread is about recomendations
for JTAG debugger evaluation (i.e. which one would one recommend)
whereas here I wanted to know how it works in detail behind the
scenes. While I do have a (basic) understanding of JTAG, the missing
link is/was how debuggers impelent this.

The other thread you most likely refer to "What is JTAG was[Re: What
is ICE?....] " is not specific enough about HOW it works. At least not
to the level I would like to understand it. Older posts found are less
and less "on topic" and quickly date back years.

[your highly valued answers snipped here because my news server does
not allow me to post less new text than what was present]

>The best units (IMO) impliment an open protocol such as the GDB
>remote protocol.

Thanks for this hint ! based on "GDB remote protocol" By using Goolge
I found a very intersting article on the subject here:

http://www.embedded.com/1999/9911/9911feat3.htm

Which explains very well how products work which use THIS aproach.
Still leaves a bit open how the "el cheapo" cable/dongle ones operate
though.

Again, thanks for your reply. It helped understand the difference
between the Abatron bdi2000 and company and the cheaper ones seen from
a users perspecitve. 

Markus

PS:
Speaking of Abatron - the funny thing is that even though Abatron main
office is located only 2 miles away from where I live (Switzerland), I
have to pay ~$400 more than if I would purchase it in the US or in
Great Britain or virutally any other place....

Markus Zingg wrote:
> http://www.embedded.com/1999/9911/9911feat3.htm
> 
> Which explains very well how products work which use THIS aproach.
> Still leaves a bit open how the "el cheapo" cable/dongle ones operate
> though.

Didn't Grant already say it? :) Raven, Wiggler etc just pass the 
JTAG signals (clock, data out, data in, test mode select) between 
your chip and the PC software, with no fancy target-device specific 
command conversion firmware doing any magic in between.

Essentially all that the generic JTAG allows, is a boundary scan of 
the chip pin states. Programming, memory readout and debugging 
functions are proprietary, vendor or part/series specific extensions 
to JTAG commands.

The el-cheapos handle the extensions in the PC software. The more 
expensive ones do it inside the dongle in firmware (but the PC 
software then must also cope with the protocol the dongle firmware 
uses, this /may/ be a very vendor or device specific protocol!! ;-)

With el-cheapo cables (Raven, Wiggler) you're potentially able to 
use for a lot more of different devices. The only problem I can 
think of is that they are "a bit" slow. And they aren't supported by 
all debugger, programmer, IDE tools - one obvious reason is that 
these vendors want to sell you their own expensive proprietary 
interface dongles, so you won't mistakenly use your own too cheap $5 
interface cable... ;-)

  - Jan

>Didn't Grant already say it? :)

It must be a language thing on my part then in that I aparently have
problelms to formulate the questions clear enough in english which is
not my native language. I'm sorry for that. 

I knew that the Dongles use JTAG and software on the PC side to drive
them etc. I probably should have (better) asked then if support for a
specific processor in GDB also includes a STANDARDIZED way to access
such Dongle/el cheapo solutions. After reading your reply my
conclusion is that unfortunately this is NOT the case - yet another
good reason to choose one of the more advanced debuggeres. 

I currently settle around the Abatron bdi2000 which generally seems to
get real good critcis.

I also got the impression that it's a good idea to take a close look
at the GDB sources available and look at existing support for such
dongles. I'm hope this will give a final answer on the degree of
standartisation.

> Raven, Wiggler etc 
[your answer snipped because of newsserver restrictions here...]
> one obvious reason is that 
>these vendors want to sell you their own expensive proprietary 
>interface dongles, so you won't mistakenly use your own too cheap $5 
>interface cable... ;-)

Again, thanks for enlightening me.

Markus

On 2005-09-28, Markus Zingg <m.zingg@nct.ch> wrote:

> I knew that the Dongles use JTAG and software on the PC side
> to drive them etc. I probably should have (better) asked then
> if support for a specific processor in GDB also includes a
> STANDARDIZED way to access such Dongle/el cheapo solutions.

Nope.  

Besides the GDB remote protocol, about the only other standard
I know about that could be used to talk to JTAG units was the
old Arm Debugging Protocol implimented by the Angle ROM monitor
as well as a couple different JTAG units (an old one from ARM
that's discontinued, and the Jeeni from EPI).  Both of those
were higher-end "intelligent" interfaces.

I don't think there's ever been any sort of a standard for how
the "dumb" interfaces worked.

> After reading your reply my conclusion is that unfortunately
> this is NOT the case - yet another good reason to choose one
> of the more advanced debuggeres. 
>
> I currently settle around the Abatron bdi2000 which generally
> seems to get real good critcis.

If you've got room in the budget for it, the BDI2000 is a good
product.

> I also got the impression that it's a good idea to take a
> close look at the GDB sources available and look at existing
> support for such dongles. I'm hope this will give a final
> answer on the degree of standartisation.

-- 
Grant Edwards                   grante             Yow!  I will establish
                                  at               the first SHOPPING MALL in
                               visi.com            NUTLEY, New Jersey...

>> STANDARDIZED way to access such Dongle/el cheapo solutions.
>
>Nope.  

Thanks for clarifying this.

[snip]
>I don't think there's ever been any sort of a standard for how
>the "dumb" interfaces worked.

Ok, I think an easy way for them to go could be to also use the remote
interface by connecting to the loopback IP address and then do the
proprietary stuff from there...

Markus