Quartus II 11.1sp2 programmer does not recognize EPC2LC20

[Altera_Forum]

Quartus II 11.1sp2 programmer does not recognize EPC2LC20 over JTAG using USB Blaster on Windows XP (32 bit) computer: 

 The programming software & USB Blaster function properly in several applications programming Altera devices with integral EP memory and using a POF file. This device is programmed with a JAM file, but it does not get to the point where that matters. After bringing up Quartus II and reading the JTAG chain it reports an unknown device code. The JTAG chain consists of a single EPC2LC20 (which is being used to configure an EP1K50). Verified connections match Altera requirements, voltages in spec, even see the TCK, TMS, TDI & TDO signals wiggling when auto-configuring the chain.    The customer claims that they use an older version of Quartus software without problems, but I do not see download links to anything but current software on Altera's support site.    Thanks in advance!

[Altera_Forum]

--- Quote Start ---  Quartus II 11.1sp2 programmer does not recognize EPC2LC20 over JTAG using USB Blaster on Windows XP (32 bit) computer:   ...   The customer claims that they use an older version of Quartus software without problems, but I do not see download links to anything but current software on Altera's support site.    Thanks in advance!  --- Quote End ---    About getting older versions of Quartus software, try this link (ftp://ftp.altera.com/outgoing/release).

[Altera_Forum]

What does `jtagconfig --debug` report?

[Altera_Forum]

Thanks to you both for the prompt responses! FYI I downloaded the version of the tool that the customer uses (8.1) and it doesn't perform any differently. 

 Here's a copy of the output from jtagconfig (talking to a single EPC2LC20 through a USB Blaster):   C:\altera\11.1sp2\qprogrammer\bin>jtagconfig --debug 1) USB-Blaster [USB-0] 020041F9 (IR=11) Captured DR after reset = (0020041F9) [33] Captured IR after reset = (2A9) [11] Captured Bypass chain = (2) [2]   I connected the USB Blaster to another board design for which the Altera device can be programmed and here are the results:   C:\altera\11.1sp2\qprogrammer\bin>jtagconfig --debug 1) USB-Blaster [USB-0] 172560DD EPM(3256A|7256AE) (IR=10) Captured DR after reset = (172560DD) [32] Captured IR after reset = (155) [10] Captured Bypass chain = (0) [1]

[Altera_Forum]

... while I would still appreciate any feedback on the jtagconfig --debug responses above, I did want to close the loop on the thread regarding what was found to be the issue ...  

 I took the boards to the customer's site and found that even with their USB Blaster the JTAG interface was not functional. The customer had a "Byte Blaster" setup, and with that we were able to access the EPC2 devices.    What was found to be the root cause was 5V clamping diodes that were installed on TCK, TDI, TDO and TMS. It is not clear what problem 5V clamping diodes would cause, most likely an excessive capacitave load of some sort. With the diodes removed the USB Blaster reads the correct ID code and can read and program the EPC2 device.    Thanks again for the earlier support!

[Altera_Forum]

Thanks for clearing up the problem. 

 What the failing jtagconfig --debug report shows is what jtagserver read from the chain when it tried to auto-detect it. jtagserver does the following operations:  1. Go to TEST-LOGIC-RESET state (this selects the deviceid register on devices which have it or the bypass register on devices which don't) 2. Do a DR scan to read the value scanned out of this register - try and identify the ID codes 3. Do an IR scan to check the length of the combined register. Load all ones into the IR to select the bypass registers on everything 4. Do a DR scan to check that all bypass registers behave properly and to confirm the value read back in step 2  The values read out suggest that there are two devices on the chain (bypass register length 2 - deviceID lengths 1+32, IR length 1+10), one of which is behaving very strangely. If these values don't match the actual chain on the board then some sort of signal integrity issue is likely (as you have found)