trying to understand JTAG

I think Kristoff is thinking that JTAG (being a IEEE Standard) should be the same everywhere, like RS-232 or RS-170 or Async Serial (which is NOT a ieee standard, by the way).

The truth is vendors (people that make chips) have some secret sauce they want to keep secret.

So they play lose with the "JTAG Standard".

Some for good reasons, some for "just to be pissy".

The JTAG standard does not address debuggers or programmers, its for testing logic.

So this changes the JTAG a vendor will provide.

But, they all it JTAG so people will not get confused by the "new" interface, even if they are all "new" (i.e. different).

hamilton

The way to understand this is that JTAG is a stack, a bit like the TCP/IP stack. The lower layers are specified, the upper layers are vendor-specific. And a lot of those are embedded into proprietary software and not documented.

It's a bit like trying to use a website when the only thing specified is the shapes of the network plugs and the basic signalling, and everything upwards of there needs vendor-specific support. It's a bit like that if you want to access the Microsoft website you need a MS computer running Windows, connected to the MS ISP with an MS router and talking to an MS server that runs Windows. There are occasionally alternative replacements for individual bits of the stack, but they don't form a coherent whole like the vendor tools do.

Theo

Hi Taunoo, all,

I will not reply to every message (I do not want to spam this list :-) ), so I'll just reply to one or two.

But thanks for everybody who answered in this thread.

Based on the replies here and a couple of additional videos, I think I have a bit of better understanding on how it fits together.

I found the talk of travis Goodspeed on this openjtag debugger and hacking MSP430s using the JTAG interface (defcon17) quite interesting.

If I get it correct, the IEEE document only describes layers 1 and 2, i.e. how a way to access the onchip debug logic of an IC and that's about it.

Not very much then. :-(

(...)

OpenOCD is surely on my "to try" list, once I have the debugging-interface that is supported by it.

I did notice that the AVR dragon is not on the list of supported hardware. I guess there are other factors that come into play here (I guess software-interface on how to speak to the controller).

Any advice on a cheap interface-device for a hobbyist?

Well, the AVR dragon does have a jtag interface and I did notice that both avrdude and averice have options mentioning JTAG. Does this mean this JTAG interface is only for 8Bit AVR devices with a JTAG interface and not for the 32bit ARM-based AVRs?

Cheerio! Kr. Bonne

Rick,

Op maandag 7 juli 2014 05:56:07 UTC+2 schreef rickman:

I did see the video on the EEVBLOG about JTAG's boundary scan. Very interesting.

Is there actually open-source (linux) software for this available?

Cheerio! Kr. Bonne.

Hi Hamilton,

Op maandag 7 juli 2014 06:11:21 UTC+2 schreef hamilton:

I do understand that the vendors want to avoid giving away information about the internal workings of their chips via the onchip debug system. I guess that is normal.

But, on the other hand, JTAG is just an interface, no? It just descibed how to get to the debug-hardware. It doesn't say anything about what the hardware does or how it works. Just like any other onchip debugging interface.

I fail to see how using a standardised interface is more or less "dangerous" then using your own "secret" interface.

Cheerio! Kr. Bonne.

You can get ARM Cortex M0 parts (the NXP LPC811M001JDH16FP) for $1.61 in qty 1 from DigiKey, and an ST-Link debugger for $29.95 from the same place (I think the LPC811M001JDH16FP will work with Olimex, but you need to use up two more pins). You can use the gnu ARM tools from CodeSourcery to do your development, and use Eclipse for an IDE and debugging front end.

That's pretty cheap, and the environment certainly feels 'pro' to me, since I use it to write code for customer projects.

I don't know what "danger" has to do with anything. I don't think the vendors are trying to keep any aspect of their debug interface secret. Rather I expect it is more an issue of just not wanting to spend the time and effort on releasing the information which would then require support. You can say you would like the info even without support, but once they give it out, they pretty much would need to support it without generating ill will with their customers.

It is a similar situation with the FPGA makers. In this case there may be some issues with secrecy, but mostly they don't give out info on generating a bit stream because it would be a lot of work to support with very little upside. 99.99% of their customers are happy with the provided tools and they would not sell additional chips by supporting the software. Very parallel to the JTAG issue with MCU vendors.

I think I have a bit of better understanding on how it fits together.

hacking MSP430s using the JTAG interface (defcon17) quite interesting.

debugging-interface that is supported by it.

supported hardware. I guess there are other factors that come into play here (I guess software-interface on how to speak to the controller).

The AVR debugging interface is not completely compatible with that of the ARM's, and, IIRC, the OpenOCD work is still in progress.

My recommendation is MSP430 for a beginner, and some Cortex-M3 or Cortex-M4 for later.

The Stellaris development board is a nice thing: It is powered from the USB port used for the JTAG and there is a clever piece of logic on the board so it can also work as the USB/JTAG dongle for external hardware. This meand that you can first learn to set up the processor and then start to hoist the own construction up.

The Atmel chips do work with OpenOCD, the warning is only for the USB/JTAG adapter on the development boards.

that both avrdude and averice have options mentioning JTAG.

with a JTAG interface and not for the 32bit ARM-based AVRs?

Please see above. The term JTAG is used in about as many different purposes as RS-232. JTAG as standardized does not specify an interface to programming Flash or debugging the target. It is only a peephole to the insides of the chip.

Avrdude has been working fine for me. I've never used nor needed to attempt JTAG debugging on an AVR.

You want to think again. Have been through that more than once, the reason never was about support. It is about control of who can do what with the silicon.

Dimiter

------------------------------------------------------ Dimiter Popoff, TGI

------------------------------------------------------

Well, probably. But conspiracy theories are more fun.

Well well, conspiracy theories. What is your experience to back your claim.

Anyway, whatever you say. I am years past wrestling those issues, have found out what I have found out, got my solutions etc. I would expect people here to be somewhat more inquiring than the general public (i.e. to not readily repeat what they have just heard a lot of times) though - but I have always been too optimistic, I guess.

Dimiter

------------------------------------------------------ Dimiter Popoff, TGI

------------------------------------------------------

I don't know about optimistic, but gullible for sure. I think Tim was writing tongue in cheek.

As for you, what do you base your claim on for them wanting to "control" what you do with their silicon? I think it is purely about the level of effort they have to provide to get the maximum return. Any control of your design is a secondary result and not of any real interest to "them". I can only provide as proof that they are capitalists and clearly have a profit motive. You could even say they are Ferengi.

If it has been tongue in cheek I have simply missed that.

My point is exactly that you are saying what you say without knowing what you are talking about.

My experience includes enough fights - some of them successful - to get to documentation of that kind. Much of the fights are reflected on newsgroups you do read and much of which you have read already so I am not going to repeat myself. Suffice it to say one manufacturer spent months after having my NDA to provide me just with the data allowing me to program a CPLD via JTAG having a JEDEC file. Did you ever have a product doing that in the field, or did you ever try to get such data. There are other manufacturers too, e.g. a processor manufacturer simply would not give me the data on the JTAG debug facilities (which they give to selected tool vendors), NDA or not.

Dimiter

------------------------------------------------------ Dimiter Popoff, TGI

------------------------------------------------------