Cyclone IV no JTAG access after PS configuration

[Altera_Forum]

Hi 

I use passive serial configuration for a EP4CE10F17C8 device (a DSP controls the nSTATUS, nCONFIG, DCLK and DATA0 ports of the FPGA) After configuration the FPGA releases CONF_DONE as it should, and the user mode is correctly entered. The DSP releases nSTATUS, nCONFIG, DATA0 and DCLK, these signals are tied to VCCIO by pull up resistors.    The problem is: After PS configuration there is no JTAG access any more by the USB blaster for signal tap debugging. Error (209040): Can't access JTAG chain Error (209012): Operation failed   If the hardware is in a "virgin" state, that means no configuration by the DSP takes place, JTAG access by the USB blaster works fine.   This is what the Quartus JTAG Chain Debugger says: 1) The TAP controller can be reset or put into idle state (but this does not help) 2) If I run "Test JTAG Chain", usually the device cannot be identified (wrong or ambiguous ID, or sometimes even several devices are detected)   Is this a hidden feature of Cyclone IV E devices or a undocumented anti-tampering mechanism?  I always thought JTAG works independently of any other configuration schemes. I assume some JTAG-related registers are overwritten or corrupted during PS configuration, but which ones, and how could this be avoided?  Is there any way to clear the device configuration in order to regain access using the Quartus JTAG Chain Debugger?  Any suggestions will be appreciated.  regards peter

[Altera_Forum]

This is not an undocumented feature. There is something wrong with your hardware. 

 When you use the JTAG debugger, probe the JTAG pins. When you press the check IDCODE, the debugger will generate JTAG transitions on TCK and TMS to reset the JTAG TAP, which defaults to loading the IDCODE JTAG instruction. TCK and TMS will then be toggled to move the TAP into the Shift-DR state and the IDCODE should be output on TDO. See the attached scope trace.  If you don't see valid logic levels on these three signals, then you may have an issue. To test TDI, use the other tab of the debugger and move the TAP to the Shift-DR state, and enter a 32-bit value, eg., 0xAAAAAAAA. Then shift that into the TAP. The response will be the JTAG ID code, but TDI will be toggled.  Cheers, Dave

[Altera_Forum]

I am getting similar issue on Arria V evaluation board as well but mainly by programming thru SignalTap. The only workaround I found so far is shuffle around the SignalTap buses, and re-compile. Next time around a good chance is it will work, but also a fairly high 25% chance more time to be wasted. My device is only about 1/3 full but it takes an hour to compile... 

 I wonder if the re-compile at least works for you.  Jeng

[Altera_Forum]

--- Quote Start ---  I am getting similar issue on Arria V evaluation board as well but mainly by programming thru SignalTap. The only workaround I found so far is shuffle around the SignalTap buses, and re-compile. Next time around a good chance is it will work, but also a fairly high 25% chance more time to be wasted. My device is only about 1/3 full but it takes an hour to compile...  I wonder if the re-compile at least works for you.  Jeng  --- Quote End ---    The reason why I did not have JTAG access after PS configuration was hardware-related. The Microprocessor on the board coupled noise and spikes into the JTAG's TCK line, which caused state machine transitions into unexpected states.  But your problem sounds familiar to me as well. I observed it frequently with older quartus versions. Which version do you use? Peter

[Altera_Forum]

I am using 12.1 and 13.0 concurrently and experience the problem on either version.  

There seem to be a magic number "set_output_delay -clock altera_reserved_tck -add_delay 20 [get_ports {altera_reserved_tdo}]". I do get a timing error of -14ns slack when it fails versus a good case it won't show up in TimeQuest report, so I really wonder if this number needs to be tweak for different devices we use.  Jeng