Problem with CRC Error Functionality, JTAG/AS Config Scheme

Altera_Forum · ‎09-14-2010

Hello all,

Currently I have a system arranged to use both the active serial and JTAG configuration schemes, laid out as specified in the Cyclone III handbook(figure 9-29). I'm using a Cyclone III EP3C10F256I7N along with an EPCS4 for AS. The system is programmed using AS and the JTAG interface is only being used to access the CRC registers by way of a .jam file.

My goal is to test the ability of the system to reconfigure when a CRC error is encountered. Quartus has been configured properly and the CRC_ERROR pin is routed to a coldfire processor on the system. In theory the system should detect the transition to the high state on CRC_ERROR and then pull nCONFIG low to induce a reconfigure(which will clear the CRC error).

Now, to accomplish this I believe I've referenced all of the appropriate documentation in regards to inducing the error through JTAG commands delivered by a .jam file. I started with the code provided by Altera in their knowledge base article and modified it slightly to capture the previous CRC value and print it. This way I am able to read back what the proper value is and I can write this expected value to the CRC register to clear the error manually without a reconfigure, if I needed to.

When an incorrect CRC value is written the system indeed initiates a reconfigure. It pulls nCONFIG low and the CONF_DONE reacts as we expect. However once CONF_DONE goes high and the FPGA recalculates the CRC(about 6ms, consistent with the documentation), the CRC_ERROR pin is again asserted. Using the .jam file to write a CRC value and simultaneously capture and display the previous CRC value shows why: the CRC register reads back all 0's.

What could be causing this register to be written this way? Is this an issue with using JTAG to initiate the error and then reconfiguring using an AS configuration device?

Any help anyone could provide would be greatly appreciated!

Here is the jam code for reference:

NOTE MAX_FREQ "10000000";
ACTION CONFIG_IO = CORRUPT;
PROCEDURE CORRUPT;
BOOLEAN X = 0;
BOOLEAN dout;
DRSTOP IDLE;
IRSTOP IDLE;
STATE IDLE;
IRSCAN 10, $015;
DRSCAN 32, $FAB89463, CAPTURE dout;
PRINT "CRC REG:";
PRINT dout, dout, dout, dout, " ", dout, dout, dout, dout, " ", dout, dout, dout, dout, " ", dout, dout, dout, dout, " ", dout, dout, dout, dout, " ", dout, dout, dout, dout, " ", dout, dout, dout, dout, " ", dout, dout, dout, dout;
STATE RESET;
STATE IDLE;
EXIT 0;
ENDPROC;

Altera_Forum · ‎09-16-2010

Speaking with Altera reveals that you must cycle power to the device in order to properly reconfigure when testing the CRC error functionality. This is problematic since we must demonstrate this functionality in a final production configuration, and can't just assume a naturally occurring CRC error will allow the device to reconfigure the device(including the CRC register) properly. with cyclone iii devices it is impossible to test and demonstrate a configuration where a crc error causes a reconfigure.

This means we must use the CRC error signal to actually cycle power to the device. I understand the power sequencing in the Cyclone III's is very flexible, but are there any problems with shutting down just the 1.2V core voltage for ~20ms to cause the power cycle/reconfigure?

Altera_Forum · ‎12-11-2013

I see exactly the same reaction with a Cyclone IV device. It keeps on reconfiguring until a power cycle.

Altera_Forum · ‎12-11-2013

--- Quote Start ---

I understand the power sequencing in the Cyclone III's is very flexible, but are there any problems with shutting down just the 1.2V core voltage for ~20ms to cause the power cycle/reconfigure?

--- Quote End ---

The handbooks usually have a statement along the lines of "if you cannot meet the power-on power supply sequence requirements, assert nCONFIG until power is stable".

For your case, I'd recommend holding nCONFIG low, power-cycling the core voltage, and then release nCONFIG. If that works, then you have a solution that is consistent with the handbook recommendations.

Cheers,

Dave