Hi all, After having played around with a MSP430 on a TI launchpad, I got interested in onchip debugging. (the TI-launchpad has a spy-by wire interface which works quite nicely) In the mean time, I have a AVRdragon to play with AVRs using debug-wire and I have also ordered a pickit3. While using the dragon, I got curious about that JTAG-connector on that board, so I started looking at JTAG too. I have a STM32 based olimex board I can use for this. For MSP430 and AVR, it's quite simple to understand. You have - your device - the debugging interface-board (onboard on the TI launchpad board or the SPI or dW interfaces on the dragon) - a "proxy" application: mspdebug, avarice - gdb that talks to the proxy application Sofar, so good. But I have some problems trying to get around how JTAG works. JTAG is supposed to be a IEEE standard, but - connectors (10, 14 or 20 pins) do not seams to be standardised - there are quite a few different interface-boards out there, but quite a few of them are marked as "works only with <some device" - do I need to use a "proxy" application for JTAG-debugging? How does openocd fit into this? Is that the "proxy" application for JTAG? - The AVR DRAGON does not seams to be supported by openocd. - Say I want to troubleshoot some other JTAG-based device (say a raspberry pi), do I need again some other interface-board or can any JTAG-interface board work with an JTAG-enabled board (if you can wire them correctly?) Anybody any links to websites / resources that explain a generic setup of JTAG-debugging (using linux). Cheerio! Kr. Bonne.
trying to understand JTAG
Started by ●July 6, 2014
Reply by ●July 7, 20142014-07-07
On 7/6/14, 5:18 PM, Kristoff Bonne wrote:> Hi all, > > > After having played around with a MSP430 on a TI launchpad, I got interested in onchip debugging. (the TI-launchpad has a spy-by wire interface which works quite nicely) > > > In the mean time, I have a AVRdragon to play with AVRs using debug-wire and I have also ordered a pickit3. While using the dragon, I got curious about that JTAG-connector on that board, so I started looking at JTAG too. I have a STM32 based olimex board I can use for this. > > > > For MSP430 and AVR, it's quite simple to understand. > > You have > - your device > - the debugging interface-board (onboard on the TI launchpad board or the SPI or dW interfaces on the dragon) > - a "proxy" application: mspdebug, avarice > - gdb that talks to the proxy application > > > > Sofar, so good. > But I have some problems trying to get around how JTAG works. > > JTAG is supposed to be a IEEE standard, but > - connectors (10, 14 or 20 pins) do not seams to be standardised > - there are quite a few different interface-boards out there, but quite a few of them are marked as "works only with <some device" > > - do I need to use a "proxy" application for JTAG-debugging? How does openocd fit into this? Is that the "proxy" application for JTAG? > > - The AVR DRAGON does not seams to be supported by openocd. > > - Say I want to troubleshoot some other JTAG-based device (say a raspberry pi), do I need again some other interface-board or can any JTAG-interface board work with an JTAG-enabled board (if you can wire them correctly?) > > > > Anybody any links to websites / resources that explain a generic setup of JTAG-debugging (using linux). > > > > > Cheerio! Kr. Bonne. >Basic JTAG uses 4 or 5 signals (Test Clock, Test Data In, Test Data Out, Test Mode Select, and an optional Test Reset). This basic interface is often put on a 10 pin connector. The basics of this operation is fairly well defined by the IEEE standard, but the operation of some of the bit patterns are vender defined, (for things beyond the basic pin test interface) which are used to implement many of the debug operations. A processor JTAG interface typically adds a few signals and is put on a 14 or 20 (or more) pin connector. Even though these connectors contain additional signals, they are often called "JTAG" connectors, but these additional signals are NOT specified by the IEEE JTAG standard. Different processors may add different signals as their additions, some processors use more "standardized" setups then others. So yes, different boards will work for different groups of processors.
Reply by ●July 7, 20142014-07-07
On 7/6/2014 11:33 PM, Richard Damon wrote:> On 7/6/14, 5:18 PM, Kristoff Bonne wrote: >> Hi all, >> >> >> After having played around with a MSP430 on a TI launchpad, I got >> interested in onchip debugging. (the TI-launchpad has a spy-by wire >> interface which works quite nicely) >> >> >> In the mean time, I have a AVRdragon to play with AVRs using >> debug-wire and I have also ordered a pickit3. While using the dragon, >> I got curious about that JTAG-connector on that board, so I started >> looking at JTAG too. I have a STM32 based olimex board I can use for >> this. >> >> >> >> For MSP430 and AVR, it's quite simple to understand. >> >> You have >> - your device >> - the debugging interface-board (onboard on the TI launchpad board or >> the SPI or dW interfaces on the dragon) >> - a "proxy" application: mspdebug, avarice >> - gdb that talks to the proxy application >> >> >> >> Sofar, so good. >> But I have some problems trying to get around how JTAG works. >> >> JTAG is supposed to be a IEEE standard, but >> - connectors (10, 14 or 20 pins) do not seams to be standardised >> - there are quite a few different interface-boards out there, but >> quite a few of them are marked as "works only with <some device" >> >> - do I need to use a "proxy" application for JTAG-debugging? How does >> openocd fit into this? Is that the "proxy" application for JTAG? >> >> - The AVR DRAGON does not seams to be supported by openocd. >> >> - Say I want to troubleshoot some other JTAG-based device (say a >> raspberry pi), do I need again some other interface-board or can any >> JTAG-interface board work with an JTAG-enabled board (if you can wire >> them correctly?) >> >> >> >> Anybody any links to websites / resources that explain a generic setup >> of JTAG-debugging (using linux). >> >> >> >> >> Cheerio! Kr. Bonne. >> > > Basic JTAG uses 4 or 5 signals (Test Clock, Test Data In, Test Data Out, > Test Mode Select, and an optional Test Reset). This basic interface is > often put on a 10 pin connector. The basics of this operation is fairly > well defined by the IEEE standard, but the operation of some of the bit > patterns are vender defined, (for things beyond the basic pin test > interface) which are used to implement many of the debug operations. > > A processor JTAG interface typically adds a few signals and is put on a > 14 or 20 (or more) pin connector. Even though these connectors contain > additional signals, they are often called "JTAG" connectors, but these > additional signals are NOT specified by the IEEE JTAG standard. > > Different processors may add different signals as their additions, some > processors use more "standardized" setups then others. So yes, different > boards will work for different groups of processors.As has been observed, there are many things not specified by the IEEE document(s) such as the connector. I believe what is defined in the IEEE document(s) is how to use JTAG for boundary scan which means you can peek and poke the I/Os. They provide an extension mode which can be used for custom functions which software debug falls under. So the details of getting bits into and out of a debug port using the JTAG interface are standardized, but the entire protocol above that of what the bits mean and do is not standardized. I'm afraid I don't know much about openocd. -- Rick
Reply by ●July 7, 20142014-07-07
On Sun, 06 Jul 2014 14:18:28 -0700, Kristoff Bonne wrote:> Hi all, > > > After having played around with a MSP430 on a TI launchpad, I got > interested in onchip debugging. (the TI-launchpad has a spy-by wire > interface which works quite nicely) > > > In the mean time, I have a AVRdragon to play with AVRs using debug-wire > and I have also ordered a pickit3. While using the dragon, I got curious > about that JTAG-connector on that board, so I started looking at JTAG > too. I have a STM32 based olimex board I can use for this. > > > > For MSP430 and AVR, it's quite simple to understand. > > You have - your device - the debugging interface-board (onboard on the > TI launchpad board or the SPI or dW interfaces on the dragon) > - a "proxy" application: mspdebug, avarice - gdb that talks to the proxy > application > > > > Sofar, so good. > But I have some problems trying to get around how JTAG works. > > JTAG is supposed to be a IEEE standard, but - connectors (10, 14 or 20 > pins) do not seams to be standardised - there are quite a few different > interface-boards out there, but quite a few of them are marked as "works > only with <some device" > > - do I need to use a "proxy" application for JTAG-debugging? How does > openocd fit into this? Is that the "proxy" application for JTAG? > > - The AVR DRAGON does not seams to be supported by openocd. > > - Say I want to troubleshoot some other JTAG-based device (say a > raspberry pi), do I need again some other interface-board or can any > JTAG-interface board work with an JTAG-enabled board (if you can wire > them correctly?) > > > > Anybody any links to websites / resources that explain a generic setup > of JTAG-debugging (using linux).As Richard mentioned, different processor vendors' JTAG setups are, well, different. The exception is that the ARM Cortex (or maybe just the Cortex M) JTAG interface is standard. In that case there is a "generic" setup. I've used the Olimex JTAG adapter successfully on two different manufacturer's Cortex M parts (M3 and M4), and I've used the ST Link adapter successfully on ST parts (Cortex M0 and M4) and NXP (Cortex M0) parts. If you're using OpenOCD and both a supported processor and a supported adaptor, then the process works very well. There are the usual rough spots that trip you, but no more than I've experienced with any other tool chain, and less than some. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
Reply by ●July 7, 20142014-07-07
>> On 7/6/14, 5:18 PM, Kristoff Bonne wrote: >>> Hi all,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
Reply by ●July 7, 20142014-07-07
On 7.7.14 07:00, Tim Wescott wrote:> On Sun, 06 Jul 2014 14:18:28 -0700, Kristoff Bonne wrote: > >> Hi all, >> >> >> After having played around with a MSP430 on a TI launchpad, I got >> interested in onchip debugging. (the TI-launchpad has a spy-by wire >> interface which works quite nicely) >> >> >> In the mean time, I have a AVRdragon to play with AVRs using debug-wire >> and I have also ordered a pickit3. While using the dragon, I got curious >> about that JTAG-connector on that board, so I started looking at JTAG >> too. I have a STM32 based olimex board I can use for this. >> >> >> >> For MSP430 and AVR, it's quite simple to understand. >> >> You have - your device - the debugging interface-board (onboard on the >> TI launchpad board or the SPI or dW interfaces on the dragon) >> - a "proxy" application: mspdebug, avarice - gdb that talks to the proxy >> application >> >> >> >> Sofar, so good. >> But I have some problems trying to get around how JTAG works. >> >> JTAG is supposed to be a IEEE standard, but - connectors (10, 14 or 20 >> pins) do not seams to be standardised - there are quite a few different >> interface-boards out there, but quite a few of them are marked as "works >> only with <some device" >> >> - do I need to use a "proxy" application for JTAG-debugging? How does >> openocd fit into this? Is that the "proxy" application for JTAG? >> >> - The AVR DRAGON does not seams to be supported by openocd. >> >> - Say I want to troubleshoot some other JTAG-based device (say a >> raspberry pi), do I need again some other interface-board or can any >> JTAG-interface board work with an JTAG-enabled board (if you can wire >> them correctly?) >> >> >> >> Anybody any links to websites / resources that explain a generic setup >> of JTAG-debugging (using linux). > > As Richard mentioned, different processor vendors' JTAG setups are, well, > different. > > The exception is that the ARM Cortex (or maybe just the Cortex M) JTAG > interface is standard. In that case there is a "generic" setup. I've > used the Olimex JTAG adapter successfully on two different manufacturer's > Cortex M parts (M3 and M4), and I've used the ST Link adapter > successfully on ST parts (Cortex M0 and M4) and NXP (Cortex M0) parts. > > If you're using OpenOCD and both a supported processor and a supported > adaptor, then the process works very well. There are the usual rough > spots that trip you, but no more than I've experienced with any other > tool chain, and less than some.Another vote for OpenOCD. The OpenOCD team has done very good job taking care of the heavy lifting of JTAG debugging. My experience is of FT2232-based dongles, Olimex, Amontec and TI/ Stellaris dev board. All work fine, as well as the ST development boards. I have used them with ARM7TDMI, Cortex-M3 and Cortex-M4. A warning about Atmel Cortex boards: There is a JTAG adapter on board, called J-Link. It is nearly a standard J-Link, but the USB device ID and protocol are so much bastardized that it works only with Atmel Studio (which is a monster based on Microsoft Visual Studio, so it is unusable for a Linux/Unix user). -- Tauno Voipio
Reply by ●July 7, 20142014-07-07
hamilton <hamilton@nothere.com> wrote:> 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.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
Reply by ●July 9, 20142014-07-09
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.>> As Richard mentioned, different processor vendors' JTAG setups are, well, >> different.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. :-(>> The exception is that the ARM Cortex (or maybe just the Cortex M) JTAG >> interface is standard. In that case there is a "generic" setup. I've >> used the Olimex JTAG adapter successfully on two different manufacturer's >> Cortex M parts (M3 and M4), and I've used the ST Link adapter >> successfully on ST parts (Cortex M0 and M4) and NXP (Cortex M0) parts.(...)> Another vote for OpenOCD. The OpenOCD team has done very good job > taking care of the heavy lifting of JTAG debugging.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).> My experience is of FT2232-based dongles, Olimex, Amontec and TI/ > Stellaris dev board. All work fine, as well as the ST development > boards. I have used them with ARM7TDMI, Cortex-M3 and Cortex-M4.Any advice on a cheap interface-device for a hobbyist?> A warning about Atmel Cortex boards: There is a JTAG adapter on > board, called J-Link. It is nearly a standard J-Link, but the > USB device ID and protocol are so much bastardized that it works > only with Atmel Studio (which is a monster based on Microsoft > Visual Studio, so it is unusable for a Linux/Unix user).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?> Tauno VoipioCheerio! Kr. Bonne
Reply by ●July 9, 20142014-07-09
Rick, Op maandag 7 juli 2014 05:56:07 UTC+2 schreef rickman:> As has been observed, there are many things not specified by the IEEE > document(s) such as the connector. I believe what is defined in the > IEEE document(s) is how to use JTAG for boundary scan which means you > can peek and poke the I/Os. They provide an extension mode which can be > used for custom functions which software debug falls under.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?> RickCheerio! Kr. Bonne.
Reply by ●July 9, 20142014-07-09
Hi Hamilton, Op maandag 7 juli 2014 06:11:21 UTC+2 schreef hamilton:> 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".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.> hamiltonCheerio! Kr. Bonne.
