JTAG debuggers - a couple of questions

Didn't we just do this discussion last week?

And then again earlier today?

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).

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.

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.

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.

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

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]

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

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

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

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.

[your answer snipped because of newsserver restrictions here...]

Again, thanks for enlightening me.

Markus

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.

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

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

Thanks for clarifying this.

[snip]

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