Hi all,
I am reviewing a design, which has a bunch of JTAG-enabled parts. Some of the these have TRST pins, others (Xilinx) don't. I came across some interesting read on this issue:
So, my questions to Xilinx folks is: Can I somehow make sure that the TAP controller is held in reset during normal operation?
Thanks, /Mikhail
Mikhail,
The issue of the JTAG controller being upset, and causing difficulties is covered in many scientific papers, like those from Los Alamos Labs (Search for Heather Quinn), also those from JPL (Gary Swift), and also NASA.
There are well known, and well characterized SEFI (single event functional interrupt) conditions that lead to the JTAG, or the configuration state machines, or the power on reset sections of the FPGA to "go crazy."
Up until V4, these rare SEFI events (which only occur in space, from heavy ion strikes), required the device to be reprogrammed, and in some cases, powered down.
Recently, the V4 QPRO product line was announced (for radiation tolerant space flight), and the testing has shown that no power down SEFI events occur, but some SEFI events may still require "pulling PROG low" to completely restart the device. Given the rare nature of these events, the devices are finding their way into many spacecraft packages, as techniques exist for mitigation and recovery that are acceptable to these missions.
Xilinx has two space effects consortia, one in the US, and one in the EU, whose members are those companies designing spacecraft electronics, and associated universities, and national laboratories. The proceedings and reports from these consortia are listed on our website, as well as appearing on their own websites.
There are recommended techniques for monitoring the JTAG, and the configuration, so that one can recover from SEFI events contained in various applications notes (which also concern themselves with "scrubbing" so single event upsets don't accumulate and "break" a TMR'd design).
Austin
Thanks Austin. I guess this is the critical piece of information I was looking for, i.e. how likely it is that anything can happen in a non-space application...
/Mikhail
/na-gsfc-2004-04.pdf
But if you're not dealing with SEFI concerns...
JTAG reset has caused problems for some of our designs in the past which include TRST and non-TRST devices in the same chain. It's been found that some devices with TRST behave very poorly for their standard operation when TRST is asserted! Not good. Since the JTAG protocol always has a foolproof way to enter the reset state, there isn't a need to assert the external reset on the devices that include TRST.
If you have a group that does internal testing on your boards (if you aren't the guy) then you might get a better conversation on why to tie ALL the TRST pins inactive especially when you have a mixture of TRST support on the chain. My suggestion on a recent internal review where I work: find our JTAG guy and ask about disabling the TRST pin on all devices in the chain.
- John_H
One of the devices I have to deal with requires that its TRST pin must be asserted or pulsed low after power up for proper device operation!
The datasheet for another reads: "As required by the JTAG standard, this pin includes an integrated on-chip pull-up resistor. Alternatively, if the JTAG port of the part is not used on the PCB, then this pin should be tied to ground with a pull-down resistor." Yeah, great! A pull-down resistor in addition to an internal pull-up... A nice recipe for a disaster...
What a mess!...
/Mikhail
Non-space,
Virtually never.
More likely is noise, or uncontrolled garbage on the JTAG. We have actually seen a case where this happened (open pin, random noise, shuts down system through JTAG).
Austin
Not just shut down, but fry it! In the old days, I started with the XC9500 series CPLDs (not designed by Xilinx, they bought this product) and was often lazy and left the JTAG pins open until I was sure I liked the program I loaded. After smoking a couple CPLDs, I learned that this wasn't such a good idea, noise could actually reprogram the device to a pathological state that would fry it. Sometimes I noticed the chip getting hot and killed power, and was able to reprogram and have it work again. It wasn't just a latch-up, as powering off and back on resulted in the same non-operation and high current draw. But, reprogramming would often fix it. Finally I've gotten smart and put 3 pull-up resistors on the JTAG inputs so they never float. With the FPGAs, they need a checksum to match to accept the configuration, so they don't burn up, at least.
Jon
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.