JTAG boundary scan fails on dut with ArriaII GX FPGA

[Altera_Forum]

Hi all, 

 I already contacted JTAG Technologies support for this issue, but they advised me to get support from Altera...  I have a PCB equipped with an NXP MCU and an ArriaII FPGA (EP2AGX95EF29). Both devices have their own boundary scan chain. I'm using a JT3705 from JTAG Technologies to perform the boundary scan tests. It downloaded the BSD file for the EP2AGX95EF29 from the Altera website (ftp://ftp.altera.com/outgoing/download/bsdl/ep2agx95ef29.bsd). The boundary scan tests fail on the EP2AGX95EF29:  - When executing the infrastructure test, the device ID returned by the FPGA is all zero's.  - When executing the ident test only, the correct device ID is returned. According to what I learned from the JTAG Technologies support, when the ident test is executed seperately, the IDCODE opcode is not used. The FPGA returns it's device ID by default, which seems to be a IEEE 1149.1 standard. When executing the entire infrastructure test, the device identity is checked by using the IDCODE opcode from the BSD file. Apparently, the FPGA is not interpreting this IDCODE opcode as it should be. Although the capture test is running well, which means the JTAG signals TDI, TDO, TCK and TMS are connected properly to the FPGA...  - When executing an interconnection test, all nets connected to the FPGA return errors, while nets only connected to the MCU are doing fine.  Since the BSD file is already over 2 years old, I doubt there is a severe error in this file. I suppose other people have used this file too. Could somebody point me in a direction where to search for what is going wrong here? All help is appreciated :-)  Best regards, Wim

[Altera_Forum]

Hello, 

 Did you ever resolve the problem or hear back from Altera? I'm seeing an identical problem on some of the Arria II FPGAs we're testing in our production test. I'm also using the JTAG Provision tools.  Thanks, Kevin

[Altera_Forum]

Hi, 

 this was the answer that I received:     From the symptoms that you describe, I believe it is likely that the anti-tamper bit is set on your FPGA. I guess that this was not on purpose. The functionality of the anti-tamper bit is dscribed in detail in AN556: http://www.altera.com/literature/an/an556.pdf but in short it disables all JTAG functionality except for the mandatory IEEE 1149.1 instructions (which does not include the ID).  You can verify whether or not this bit is set by checking the KEY_VERIFY register as described in AN556.   If you would like me to, I can send you a .jam file (i.e. STAPL format) which you can use to check the bit either with the Quartus II software or your own boundary scan tool. If you want me to do this, then please confirm the JTAG chain configuration for the chain which contains your Arria II FPGA.  The anti-tamper bit is set by an instruction which Altera does not publish, but I can tell you that it is one of the private instructions listed in the handbook ahpater on JTAG, volume 1, chapter 11, page 11-5: http://www.altera.com/literature/hb/arria-ii-gx/aiigx_51011.pdf  The most common ways for a private instruction to be accidentally sent are: 1) toggling TCK, TMS and TDI during diagnostic testing (e.g. by probing) and accidentally sending the code. 2) A timing violation which means that a code is incorrectly interpretted at the FPGA.