USB Blaster and other JTAG devices in chain

[Altera_Forum]

hello, 

 I have a board with three devices that are connected to each other in a JTAG chain: CPU, FPGA (Altera Cyclon IV), PCI-Express switch. We connected a USB-Blaster to the chain JTAG connector, and using the Quartus started to debug the FPGA. What happened is: the whole system stopped functioning. We suspect the CPU and PCIe switch probably went into JTAG mode. (1) Is there a way to debug the FPGA, with the other devices in the chain, without the above described effects? I mean, is there a way to configure the other devices in the chain (cpu and switch) to disregard the TCK/TMS signals they see, so they continue to work normally and the FPGA could be debugged? (2) Is the only solution we have is put 0ohm resistors on TCK/TMS to all JTAG devices, and when we want to debug the FPGA, remove the resistors so the other JTAG devices will not get any JTAG signals? (TDI/TDO can be bypassed) (3) The CPU and switch have a TRST signal. Can we use this signal to have them work normally and not get affected by the FPGA debug? (3) Can you suggest a software work-around for the problem, or other suggestions to help cope with the problem?   thank you Gil Hershman

[Altera_Forum]

The question goes to the other device's vendors, I think. Besides initially reading all device ID registers in the chain, I would expect Quartus to bypass the other devices. JTAG is designed this way. You also shouldn't need to use TRST to operate the JTAG interface.  

 But you can try to pull TRST low to prevent the other devices from acting on misunderstood JTAG commands. If TRST is floating, it may be actually a reason for the unexpected behaviour.  To operate Quartus tools with third party devices in the JTAG chain, their BSDL files must be known to Quartus.

[Altera_Forum]

Thank you for the reply. 

I would also expect Quartus to bypass the other devices (for example, when programming the FPGA).   TRST is not floating, it is held high. I also think of using TRST low to hold the devices in normal mode. I am wondering if holding TRST low for the duration of the FPGA debug mode is the right way, or disconnecting TCK/TMS/TDI/TDO from the other devices is the right thing to do.   Is there any ALTERA document on the subject?

[Altera_Forum]

What happens if you select the JTAG Chain Debugger (Quartus -> Tools -> JTAG Chain Debugger)? It will probably just tell you that it can't detect any Altera devices but it might shed more light. 

 David

[Altera_Forum]

I will have to setup the board and check that. 

Will reply here in the forum.

[Altera_Forum]

Did you define the other devices in the chain description file? It's necessary, to specify the correct instruction register length, otherwise they can't be bypassed (and access to the Altera devices also won't work). I previously said, the data should be imported from BSDL files, but they can be entered manually as well.

[Altera_Forum]

hello, 

 Few more details: We upload the configuration file to the FPGA through JTAG using the programmer. When we do that, additional two non-Altera devices are well defined (using respective bsdl files). When we finish programming and test the board, communication with the devices that are attached to the downstream of the PCIe switch fail. Meaning , communication with few internal parts of the PCIe switch fails. Further investigation revealed, the configuration space registers of the upstream port in the PCIe switch were changed. It happened during the FPGA JTAG configuration upload. We bypassed the problem by bypassing the CPU/PCIe-switch TDI/TDO (connect TDI to TDO) and by tying the TRST pins of both to GND. This is a temporary solution. Question remains: how did this FPGA programming affect the PCIe internal registers?  Thank you Gil Hershman