Can't access Jtag error

[Rmc_Arira]

I am using a MAX 10 device:  10M04SCU169C8G

I used Quartus 17.0 to synthesize and build the FPGA

I have tried using the stand alone programmer versions 17 and 18.

I have tried two different byte blasters.

I have tried on three different computers, all of which have successfully configured Intel/Altera FPGAs in the recent past using the Byte Blaster

When I connect the Byte Blaster and do an "Auto Detect" it properly identifies the part.  I have examined the JTAG signals with a scope and everything looks good.

When I try to do any programming operation, including "Blank-Check", I get :

Error (209040): Can't access JTAG chain

A little more background: I work for a company that does contract work. Normally I would be the engineer who did the initial board bring up.  For this client, however, they wanted to do the initial bring up and came back to us only when there were issues they couldn't deal with.  

The client obviously was able to program the FPGA as it has at least some functionality.  There is a 'heartbeat' LED that is blinking in the expected pattern. The FPGA controls other power supplies which have properly sequenced up. So the MAX 10 obviously programmed properly at least once.

In searching this problem I spotted forum messages regarding the use of JTAG pins as general I/O.  I actually didn't know I could do that!  I am certainly not using any of the JTAG pins as I/O and they do not have any assignments in the .qsf file.  The JTAGEN pin is pulled high. 

I have tried programming with both the .sof and .pof files, same result.

When I attempt to program or blank check the programmer starts with:

Info (209060): Started Programmer operation at Fri Jul 10 16:19:28 2020
Info (209017): Device 1 contains JTAG ID code 0x0318A0DD

It obviously can communicate with the MAX 10 device as it is able to auto detect it and it can read the JTAG ID code.

Why can't it program/configure the part?

There is one possibility that I have been trying to research but I haven't figured out just yet, and that is the Security Bit. I have never used this option. As I don't know for sure what the client did when they initially loaded the .pof file it is possible that they set this bit.  

If the security bit had been set, would it explain this behavior? 
If so, how would I unset the bit?

Any other explanations?

Thank you

Rod

[Rmc_Arira]

Can anyone help on this?

I read other posts regarding the same error message and some indicated that the USB driver was to blame.  I don't understand how the USB Blaster can read the JTAG ID code and still fail, but I tried uninstalling the existing software (including uninstalling the driver associated with the USB device) and then re-installed version 20.2.

Same symptoms.  The device will auto detect but fail to do anything else.

[NurAiman_M_Intel]

Hi,

Thank you for contacting Intel community.

Apologize for the delay in response.

Some device might not support blank check. You may try to program the device without blank check, it should work.

Thanks.

Regards,

Aiman

[Rmc_Arira]

I tried just programming.  That was the first attempt.  Clicking on "Blank Check" was just a test to see if anything worked.  I figured that if there was a problem with the POF file blank check should still work.,

I am stuck here.  Our client has ten prototype boards that they need to get operational.  Once these have been tested they wanted to be in large scale production by the end of the year but that isn't looking promising if I have to re-layout the board to design in a different FPGA.

[NurAiman_M_Intel]

Hi,

May i know if your JTAGEN pin is enable(high) or disable? The function of JTAGEN pin is to enable JTAG pin function. If JTAGEN is enable, JTAG pin will be a dedicated pin(during configuration) and JTAG pin will be I/O pin (during user mode). Hence, if your JTAGEN pin is enable, you must make I/O pin assignments on all the JTAG pins in Pin Planner to identify the pin direction. Kindly refer to below KDB for more information:

KDB: https://www.intel.com/content/www/us/en/programmable/support/support-resources/knowledge-base/solutions/rd03222016_95.html?elq_cid=3764198&erpm_id=6303754

Let me know if you need further information.

Thanks.

Regards,

Aiman

[Rmc_Arira]

How does the part manage to Identify and pass the JTAG diagnostics if the JTAG wasn't enabled?

[NurAiman_M_Intel]

Hi,

In this case, you will need to enable the JTAGEN pin and assign JTAG pin in quartus per my previous reply.

Thanks.

Regards,

Aiman

[Rmc_Arira]

In my first message I stated that the JTAGEN pin was pulled high.

Can you tell me about the CRC_ERROR pin?

According to "Intel® MAX® 10 FPGA Configuration User Guide" this is an open drain output, which would imply that it needs a pull up resistor.  But all the reference designs show either a 10K pull down on this signal or it as been left unconnected. 

Question:  if this is open drain, why does it have a pull down?

Our design copied the reference design and has a 10K pull down on CRC_ERROR. When the board powers up, this signal is 'half high', about 1.5 volts. Other than the pull down resistor we have no other logic on this signal so the FPGA must be driving it, but I don't understand the 1.5 volts as all the VCC lines to the FPGA are connected to 3.3 volts.

The Configuration User Guide indicates that the CRC_ERROR is asserted (high) when the CRC value doesn't match.  I assume that this is from the internal FLASH configuration memory as it configures upon power up.  This suggests that the image in the FLASH memory is corrupted. 

Question:  Would a JTAG error during the process of writing the FLASH allow an incorrect image to be written? 

When I attempt to do a Verify sequence of the FPGA I see three distinct bursts of JTAG activity. The CRC_ERROR signal negates at the end of the first burst, but then asserts again at the end of the third burst. 

Question: Would the CRC_ERROR be asserted during a JTAG read operation?

Question:  Would a corrupt FLASH image prevent further JTAG operations?

Thank you

Rod

[NurAiman_M_Intel]

Hi,

CRC-Error open drain has dual purpose pin which are pull up(enable) and pull down(disable). Intel recommends you to tie the CRC_ERROR pin to VCCIO, GND, or leave the pin unconnected when the CRC error detection circuitry is disabled or when you are not using the CRC_ERROR pin.

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/dp/max-10/PCG-01018.pdf

You can try to go to Quartus -> Convert programming file -> Advance -> Tick both boxes ( Disable EPCS and disable AS mode).

Regards,

Aiman