FPGA Configuration Troubleshooter

You can use this troubleshooter to help your FPGA configuration attempt. While this troubleshooter does not cover every possible case, it does identify a majority of problems encountered during configuration. This troubleshooter can be supplemented with Altera® FPGA's Knowledge Database to help you identify and fix your configuration problem.

What is your configuration issue?

Expand All

Collapse All

Fail to initiate the EPCS or flash programming in Quartus II software

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

The dedicated JTAG pins (TCK, TMS, TDO, TDI) are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation.

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy	Implications
For direct EPCS programming through AS programming cable, check the power supply of the programming cable and the interface to the EPCS device.	The Quartus® II programmer will not be able to read/write any information from/to the EPCS device if the power supply or the interface is not stable.

If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

The version of the Quartus II software that you were using when this issue was encountered

The EPCS density (e.g. EPCS64 or EPCS128) that you were using when this issue was encountered

A description of when the failure started to happen and the failure symptoms. For example, the EPCS programming started to fail at the beginning/at the end of the programming cycle.

A screen shot of nCS, DCLK and ASDO signals probed at the FPGA end

Specify your observations after performing the recommended debug strategies

The device does not enter user mode although the CONF_DONE pin is released high at the end of the configuration cycle

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

The MSEL pins are tied to the correct MSEL setting according to the device handbook

The nCE, nCONFIG, nSTATUS and CONF_DONE pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct

The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

All the timing specifications are met

The supported flash device is used

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy	Implications
Download the latest version of the Quartus® II software. Regenerate the programming file and reconfigure the FPGA or reprogram and verify the flash using the new programming file	The latest Quartus II software might have the bug fix
Check the signal integrity of the DCLK and DATA line/bus signals	Noise at the lines/buses will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects configuration error and pulls the nSTATUS pin low
Enable the INIT_DONE option in the Quartus II software and check on the INIT_DONE pin to ensure the device exits the initialization stage	If INIT_DONE remains low after the CONF_DONE pin is released high, the device fails to exit the initialization stage. If the CLKUSR option is enabled, ensure sufficient clock cycles have been provided through the CLKUSR pin as stated in the device handbook, otherwise the device will fail to exit initialization stage. If INIT_DONE goes high after the CONF_DONE pin is released high, the device has successfully entered user mode.

The version of the Quartus II software that you were using when this issue was encountered

The FPGA part number that you were using when this issue was encountered

A screen shot of nCONFIG, nSTATUS, DCLK and DATA line/bus signals probed at the FPGA end

Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

Specify your observations after performing the recommended debug strategies

The Quartus II programmer fails to recognize the device ID

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

MSEL pins are tied to VCC or ground. Do not leave the MSEL pins floating.

The nCE, nCONFIG, nSTATUS CONF_DONE and dedicated JTAG pins (TCK, TMS, TDO, TDI) are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy	Implications
Download the latest version of the Quartus® II software. Regenerate the programming file and reconfigure the FPGA using the new programming file.	The latest Quartus II software might have the bug fix.
Check the signal integrity of the dedicated JTAG signals	Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.
Ensure the nCONFIG and nSTATUS pins have been released high before the auto-detect or program instruction is executed in the Quartus II programmer	If the nCONFIG and nSTATUS pins are not released high, the device is still in reset state or the device is not powered up properly. Therefore the device is not ready to receive any JTAG instruction including the silicon ID check instruction
Check the contact of the programming cable to the target device	If the connection in between the programming cable and the target device is not stable, the signal/data corruption in between both devices will cause the FPGA fail to receive the valid JTAG instruction from the host

The version of the Quartus II software that you were using and the error message appeared in the message window when this issue was encountered

The FPGA part number that you were using when this issue was encountered

Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

Specify your observations after performing the recommended debug strategies

The Quartus II programmer reports successful configuration but the device/devices are not configured

Which configuration scheme that you are using?

Passive Serial (PS)

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

The MSEL pins are tied to the correct PS setting according to the device handbook

The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Ensure all the timing specification are met

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy Implications Enable the INIT_DONE option in the Quartus® II software, and check on the INIT_DONE pin to ensure the device exits the initialization stage If INIT_DONE remains low after the CONF_DONE pin is released high, the device fails to exit the initialization stage. If the CLRUSR option is enabled, ensure sufficient clock cycles have been provided through the CLKUSR pin as stated in the device handbook, otherwise the device will fail to exit initialization stage. If INIT_DONE goes high after the CONF_DONE pin is released high, the device has successfully entered user mode. If CONF_DONE doesn't go high, probe at the DCLK and DATA signals. Observe both signals after the start button is clicked on the Quartus II programmer If both signals remain low, then the program instruction has not been issued to the FPGA properly.

The version of the Quartus II software that you were using when this issue was encountered

The FPGA part number that you were using when this issue was encountered

A screen shot of nCONFIG, nSTATUS, DCLK and DATA signals probed at the FPGA end

Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

Specify your observations after performing the recommended debug strategies

JTAG

Checklist
Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

MSEL pins are tied to VCC or ground. Do not leave the MSEL pins floating.

The nCE, nCONFIG, nSTATUS, CONF_DONE and dedicated JTAG pins (TCK, TMS, TDO, TDI) are tied to pull-up/pull-down resistors according to the recommended setup in the device handbook

The nCE, nCONFIG, nSTATUS, CONF_DONE and dedicated JTAG pins (TCK, TMS, TDO, TDI) are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Ensure all the timing specification are met

Debug Strategies
The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.
Strategy Implications Enable the INIT_DONE option in the Quartus® II software and check on the INIT_DONE pin to ensure the device exits the initialization stage If INIT_DONE remains low after the CONF_DONE pin is released high, the device fails to exit the initialization stage. If the CLRUSR option is enabled, ensure sufficient clock cycles have been provided through the CLKUSR pin as stated in the device handbook, otherwise the device will fail to exit initialization stage. If INIT_DONE goes high after the CONF_DONE pin is released high, the device has successfully entered user mode. If CONF_DONE doesn't go high, probe at the TDO, TDI and TCK signals If the TDI signal remains low while the TDO signal is toggling during the configuration, it means the configuration data is not going through the JTAG scan chain register to configure the CRAM bits correctly. This could be due to the JTAG program instruction is not being issued to the FPGA properly.
If your issue still persists, you may contact our technical support via mySupport for further assistance. After you have submitted a service request to mySupport, please provide the following information:

The version of the Quartus II software that you were using and the error message appeared in the message window when this issue was encountered

The FPGA part number that you were using when this issue was encountered

A screen shot of nCONFIG, nSTATUS, TDO, TDI and TCK signals probed at the FPGA end

Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

Specify your observations after performing the recommended debug strategies

The nSTATUS pin is pulled low or is toggling at the beginning of the configuration cycle

JTAG

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

MSEL pins are tied to VCC or ground. Do not leave the MSEL pins floating.

The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Ensure all the timing specification are met

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy	Implications
Download the latest version of the Quartus® II software. Regenerate the programming file and reconfigure the FPGA using the new programming file.	The latest Quartus II software might have the bug fix.
Check the signal integrity of the dedicated JTAG signals	Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.
Ensure there is no external device driving the nSTATUS pin	Driving the nSTATUS pin with an external device will drive the pin to low unexpectedly and this will interrupt the configuration process

The version of the Quartus II software that you were using and the error message appeared in the message window when this issue was encountered

The FPGA part number that you were using when this issue was encountered

A screen shot of nCONFIG, nSTATUS, TDO, TDI and TCK signals probed at the FPGA end

Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

Specify your observations after performing the recommended debug strategies

Active Serial (AS), Active Parallel (AP), Passive Serial (PS), Fast Passive Parallel (FPP)

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy

Implications

Download the latest version of the Quartus® II software. Regenerate the programming file and reprogram and verify the configuration device or flash using the new programming file.

The latest Quartus II software might have the bug fix.

Check the signal integrity of the DCLK and DATA line/bus signals

Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.

Ensure there is no external device driving the nSTATUS pin

Driving the nSTATUS pin with an external device will drive the pin to low unexpectedly and this will interrupt the configuration process

The MSEL pins are tied to the correct MSEL setting according to the device handbook

The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Ensure all the timing specification are met

Ensure the supported flash device is used

1. The version of the Quartus II software that you were using when this issue was encountered

2. The FPGA part number that you were using when this issue was encountered

3. A screen shot of nCONFIG, nSTATUS, DCLK and DATA line/bus signals probed at the FPGA end

4. Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

5. Specify your observations after performing the recommended debug strategies

The nSTATUS pin is pulled low or is toggling at the end or at different point of the configuration cycle

Active Parallel (AP)

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

The MSEL pins are tied to the correct AP setting according to the device handbook

The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Ensure the supported flash device is used/li>

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy	Implications
Download the latest version of the Quartus® II software. Regenerate the programming file and reprogram and verify the flash using the new programming file.	The latest Quartus II software might have the bug fix.
Check the signal integrity of the DCLK, DATA bus and flash control signals	Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.
Ensure the byte address of the configuration data is set to 0x020000 during the programming file generation. The default configuration boot address is 0x010000 in 16-bit word addressing, equivalent to 0x020000 8-bit byte addressing in the supported flash memory device	The incorrect address setting in the programming file causes the FPGA to read the wrong/invalid data from the parallel flash
Ensure there is no external device driving the nSTATUS pin	Driving the nSTATUS pin with an external device will drive the pin to low unexpectedly and this will interrupt the configuration process

The version of the Quartus II software that you were using when this issue was encountered

The FPGA and the flash device part number that you were using when this issue was encountered

A screen shot of nCONFIG, nSTATUS, DCLK and DATA bus signals probed at the FPGA end

Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

Specify your observations after performing the recommended debug strategies

Active Serial (AS)

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

The MSEL pins are tied to the correct AS setting according to the device handbook

The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy	Implications
Download the latest version of the Quartus® II software. Regenerate the programming file and reprogram and verify the configuration device using the new programming file.	The latest Quartus II software might have the bug fix.
Check the signal integrity of the nCS, DCLK and DATA signals	Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.
Ensure there is no external device driving the nSTATUS pin	Driving the nSTATUS pin with an external device will drive the pin to low unexpectedly and this will interrupt the configuration process

The version of the Quartus II software that you were using when this issue was encountered

The FPGA and the configuration device part number that you were using when this issue was encountered

A screen shot of nCONFIG, nSTATUS, DCLK and DATA signals probed at the FPGA end

Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

Specify your observations after performing the recommended debug strategies

JTAG

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

MSEL pins are tied to VCC or ground. Do not leave the MSEL pins floating.

The nCE, nCONFIG, nSTATUS, CONF_DONE and dedicated JTAG pins (TCK, TMS, TDO, TDI) pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Ensure all the timing specifications are met

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy	Implications
Download the latest version of Quartus® II software. Regenerate the programming file and reconfigure the FPGA using the new programming file.	The latest Quartus II software might have the bug fix.
Check the signal integrity of the dedicated JTAG signals	Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.
Ensure there is no external device driving the nSTATUS pin	Driving the nSTATUS pin with an external device will drive the pin to low unexpectedly and this will interrupt the configuration process

The version of the Quartus II software that you were using and the error message appears in the message window when this issue was encountered

The FPGA part number that you were using when this issue was encountered

A screen shot of nCONFIG, nSTATUS, TDO, TDI and TCK signals probed at the FPGA end

Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

Specify your observations after performing the recommended debug strategies

Passive Serial (PS), Fast Passive Parallel (FPP)

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

The MSEL pins are tied to the correct PS/FPP setting according to the device handbook

The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Ensure all the timing specification are met

Ensure the supported flash device is used

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy	Implications
Download the latest version of the Quartus® II software. Regenerate the programming file and reprogram and verify the flash using the new programming file.	The latest Quartus II software might have the bug fix.
Check the signal integrity of the DCLK, DATA line/bus and flash control signals	Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.
Ensure there is no external device driving the nSTATUS pin	Driving the nSTATUS pin with an external device will drive the pin to low unexpectedly and this will interrupt the configuration process

The version of the Quartus II software that you were using when this issue was encountered

The FPGA and the flash device part number that you were using when this issue was encountered

A screen shot of nCONFIG, nSTATUS, DCLK and DATA line/bus signals probed at the FPGA end

Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

Specify your observations after performing the recommended debug strategies

The nCONFIG and nSTATUS pins are released high, but the CONF_DONE pin does not go high at the end of the configuration cycle

Active Serial (AS)

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

The MSEL pins are tied to the correct AS setting according to the device handbook

The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy	Implications
Download the latest version of the Quartus® II software. Regenerate the programming file and reprogram and verify the configuration device using the new programming file.	The latest Quartus II software might have the bug fix.
Check the signal integrity of the nCS, DCLK and DATA signals, ensure there is activity on these signals in between the FPGA and the configuration device	Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.
Ensure there is no capacitance load or external device that could cause the delay on the CONF_DONE pin	Delaying or loading the CONF_DONE pin would cause the CONF_DONE fail to raise high within the valid timing window

The version of the Quartus II software that you were using when this issue was encountered

The FPGA and the configuration device part number that you were using when this issue was encountered

A screen shot of nCONFIG, nSTATUS, DCLK and DATA signals probed at the FPGA end

Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

Specify your observations after performing the recommended debug strategies

JTAG

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

MSEL pins are tied to VCC or ground. Do not leave the MSEL pins floating.

The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Ensure all the timing specification are met

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy	Implications
Download the latest version of the Quartus® II software. Regenerate the programming file and reconfigure the FPGA using the new programming file.	The latest Quartus II software might have the bug fix.
Check the signal integrity of the dedicated JTAG signals	Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.
Ensure there is no capacitance load or external device that could cause the delay on the CONF_DONE pin	Delaying or loading the CONF_DONE pin would cause the CONF_DONE to fail to raise high within the valid timing window

The version of the Quartus II software that you were using and the error message appeared in the message window when this issue was encountered

The FPGA part number that you were using when this issue was encountered

A screen shot of nCONFIG, nSTATUS, TDO, TDI and TCK signals probed at the FPGA end

Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

Specify your observations after performing the recommended debug strategies

Passive Serial (PS), Fast Passive Parallel (FPP)

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

The MSEL pins are tied to the correct AP/PS/FPP setting according to the device handbook

The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Ensure all the timing specification are met

Ensure the supported flash device is used

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy	Implications
Download the latest version of the Quartus® II software. Regenerate the programming file and reprogram and verify the flash using the new programming file.	The latest Quartus II software might have the bug fix.
Check the signal integrity of the DCLK, DATA line/bus and flash control signals	Noise in the lines/bus will interrupt the configuration process and cause data corruption. If data is corrupted during configuration, the FPGA detects a configuration error and pulls the nSTATUS pin low.
Ensure there is no capacitance load or external device that could cause the delay on the CONF_DONE pin	Delaying or loading the CONF_DONE pin would cause the CONF_DONE fail to raise high within the valid timing window

The version of the Quartus II software that you were using when this issue was encountered

The FPGA and the flash device part number that you were using when this issue was encountered

A screen shot of nCONFIG, nSTATUS, DCLK and DATA line/bus signals probed at the FPGA end

Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

Specify your observations after performing the recommended debug strategies

The nCONFIG and/or nSTATUS pins do not release high after the device is powered up

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

The nCE, nCONFIG and nSTATUS pins are connected according to the recommended setup in the device handbook. If pull-up/pull-down resistors are required, ensure the resistor values are correct.

The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy	Implications
Check the soldering contact in between the FPGA and the board surface	The nCONFIG and nSTATUS pins will not be released if the FPGA is not properly powered up or the FPGA does not exit POR successfully

The FPGA part number that you were using when this issue was encountered

A screen shot of the voltages (e.g. core voltage, configuration voltage) ramp up from the power-up stage

Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

Specify your observations after performing the recommended debug strategies

Fail to program the EPCS device through Serial Flash Loader (SFL)

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

The MSEL pins are tied to the AS configuration setting according to the device handbook

The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy	Implications
Ensure the programming cable is powered up and interfaced to the FPGA correctly	The Quartus® II programmer will not be able to read/write any information from/to the EPCS device if the power supply or the interface is not stable.
Check if the EPCS device can be programmed through an AS programming cable.	This is to ensure the functionality of the EPCS device. Skip this step if you are not able to test with an AS programming cable due to the restriction on your hardware.
Ensure the SFL image exists in the FPGA before the EPCS device is programmed	If the SFL bridge does not exist in the FPGA, then the Quartus II programmer will not able to access the ASMI interface in the FPGA to program the EPCS device
After the SFL image is configured to the FPGA, without power cycling the device try to perform auto-detect in the Quartus II programmer	If only the FPGA is detected, it signifies that the Quartus II programmer is unable to access the ASMI interface of the FPGA through the SFL bridge, or the Quartus II programmer is not able to detect the interface in between EPCS and the FPGA through the ASMI. Check the power supply and the interface of both devices, or use the SFL from the latest Quartus II software version If both FPGA and EPCS are detected, this is most likely a signal integrity issue. Check the signal integrity of the DATA0, DCLK, nCS and the ASDO pins. Noise at these signal locations will interrupt the EPCS programming process

The version of the Quartus II software that you were using when this issue was encountered

A screen shot of the error message shown in the Quartus II message window

The EPCS density (e.g. EPCS64 or EPCS128) that you were using when this issue was encountered

Specify your observations after performing the recommended debug strategies

Fail to program the parallel flash through Parallel Flash Loader (PFL)

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Ensure the supported flash device is used

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy	Implications
Ensure the programming cable is powered up and interfaced to the FPGA correctly	The Quartus® II programmer will not be able to read/write any information from/to the flash device if the power supply or the interface is not stable.
Ensure the PFL image exists in the MAX II CPLD or the FPGA before the flash device is programmed	If PFL bridge does not exist in the MAX II CPLD or the FPGA, the Quartus II software is not able to access to the flash device
After the PFL image is configured to the FPGA, without power cycling the device try to perform auto-detect in the Quartus II programmer	If only FPGA is detected, it signifies that the Quartus II programmer is unable to access the flash device through the PFL bridge. Check the power supply and the interface in between the MAX II CPLD or FPGA and the flash devices, or use the PFL from the latest Quartus II software version. If both FPGA and EPCS are detected, this is most likely a signal integrity issue. Check the signal integrity of the DATA line/bus, DCLK, the control signal pins. Noise at these signal locations will interrupt the flash programming process

The version of the Quartus II software that you were using when this issue was encountered

A screen shot of the error message shown in the Quartus II message window

The flash device (e.g. Numonyx 512MB, Spansion 128MB etc.) that you were using when this issue was encountered

Specify your observations after performing the recommended debug strategies

Decompression: Uncompressed file works but compressed file doesn't work or vice versa

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

The MSEL pins are tied to the correct MSEL setting according to the device handbook

The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy	Implications
The Quartus® II bitstream generation could be contributing to the issue. Download the latest version of the Quartus II software. Regenerate the programming file and reconfigure the FPGA or reprogram and verify the flash using the new programming file	The latest Quartus II software might have the bug fix
Ensure the CONF_DONE pin is not being delayed. Ensure there is no extra capacitance load on the CONF_DONE trace Use advance option bit setting to add the post-device bitstream pad bytes For AS configuration, use advance option bit setting to disable the CONF_DONE error check or change the program length count	Delaying the CONF_DONE causes the device to miss the CONF_DONE detect window and configuration error occurs Note: If the CONF_DONE error check is disabled, the FPGA will not check if the CONF_DONE rises correctly within the valid timing window.

Strategy

Implications

The Quartus® II bitstream generation could be contributing to the issue. Download the latest version of the Quartus II software. Regenerate the programming file and reconfigure the FPGA or reprogram and verify the flash using the new programming file

The latest Quartus II software might have the bug fix

Ensure the CONF_DONE pin is not being delayed.

Ensure there is no extra capacitance load on the CONF_DONE trace

Use advance option bit setting to add the post-device bitstream pad bytes

For AS configuration, use advance option bit setting to disable the CONF_DONE error check or change the program length count

Delaying the CONF_DONE causes the device to miss the CONF_DONE detect window and configuration error occurs Note: If the CONF_DONE error check is disabled, the FPGA will not check if the CONF_DONE rises correctly within the valid timing window.

The version of the Quartus II software that you were using when this issue was encountered

The FPGA part number that you were using when this issue was encountered

Attach the uncompressed and compressed programming files

A description of when the failure started to happen and the failure symptoms. For example, the configuration started to fail at the beginning/at the end of the programming cycle.

A screen shot of nCONFIG, nSTATUS, DCLK and DATA line/bus signals probed at the FPGA end

Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

Specify your observations after performing the recommended debug strategies

Design Security: Unencrypted file works but encrypted file doesn't work or vice versa

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

The MSEL pins are tied to the correct MSEL setting according to the device handbook

The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy	Implications
The Quartus® II bitstream generation could be contributing to this issue. Download the latest version of the Quartus II software. Regenerate the programming file and reconfigure the FPGA or reprogram and verify the flash using the new programming file	The latest Quartus II software might have the bug fix
Ensure the CONF_DONE pin is not being delayed. Ensure there is no extra capacitance load on the CONF_DONE trace Use advance option bit setting to add the post-device bitstream pad bytes For AS configuration, use advance option bit setting to disable the CONF_DONE error check or change the program length count	Delaying the CONF_DONE causes the device to miss the CONF_DONE detect window and configuration error occurs Note: If the CONF_DONE error check is disabled, the FPGA will not check if the CONF_DONE rises correctly within the valid timing window.
Ensure the device is successfully key programmed before you perform the configuration with the encrypted file	If the key is not present in the device then the device is unable to decrypt the encrypted file
Ensure the same key is used to do the file encryption and to program the device	If the key is not compatible then the device is unable to decrypt the encrypted file

The version of the Quartus II software that you were using when this issue was encountered

The FPGA part number that you were using when this issue was encountered

Attach the uncompressed and compressed programming files

A description of when the failure started to happen and the failure symptoms. For example, the configuration started to fail at the beginning/at the end of the programming cycle.

A screen shot of nCONFIG, nSTATUS, DCLK and DATA line/bus signals probed at the FPGA end

Specify if you are performing single-device or multi-device configuration. For multi-device configuration, please list the devices connected in the chain

Specify your observations after performing the recommended debug strategies

Design Security: Volatile key programming failure

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy	Implications
Download the latest version of the Quartus® II software. Regenerate the programming file and reconfigure the FPGA using the new programming file	The latest Quartus II software might have the bug fix
Ensure the device is not programmed with the non-volatile key before you perform the volatile key programming	Once a non-volatile key (one time programmable) has been programmed into the device you will not be able to program a volatile key
Ensure the VCCBAT is powered up properly	The VCCBAT is a dedicated power supply for volatile key storage. The volatile register will not be powered up if there is no VCCCBAT supply.
Ensure the same setup (same board, download cable and the Quartus II software version) is able to perform JTAG programming before you perform the volatile key programming	If JTAG programming fails, then it is not a specific volatile key programming failure.

The version of the Quartus II software that you were using when this issue was encountered

The FPGA part number that you were using when this issue was encountered

A screen shot of the error message shown in the Quartus II message window

Specify your observations after performing the recommended debug strategies

Design Security: Non-volatile key programming failure

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy	Implications
Download the latest version of the Quartus® II software. Regenerate the programming file and reconfigure the FPGA using the new programming file	The latest Quartus II software might have the bug fix
Ensure the device is not programmed with the non-volatile key before you perform the volatile key programming	Once a non-volatile key (one time programmable) has been programmed into the device you will not be able to program a volatile key
Ensure the non-volatile key programming frequency (JTAG TCK frequency) is set according to the specifications	Unregulated JTAG TCK frequency would interrupt the poly-fuse programming.
Ensure the proper download cable (for example Ethernet Blaster or JTAG technologies) is used for the non-volatile key programming.	An unsupported download cable will not enable the programming of the non-volatile key
Ensure the same setup (same board, download cable and the Quartus II software version) is able to perform JTAG programming before you perform the volatile key programming	If JTAG programming fails, then it is not a specific volatile key programming failure. Note:Please return to the Configuration Troubleshooter initial page to select JTAG related failures.

The version of the Quartus II software that you were using when this issue was encountered

The FPGA part number that you were using when this issue was encountered

A screen shot of the error message shown in the Quartus II message window

Specify your observations after performing the recommended debug strategies

Remote System Upgrade: The FPGA is not able to switch from factory page to application page

Checklist

Before you proceed to further debug your issue, you are advised to use this checklist to verify that you have followed the recommended configuration setup in your design.

The power supplies are ramped up to the appropriate voltage level according to the device datasheet and are stable throughout the operation

Debug Strategies

The following table lists some recommended debug strategies to narrow down the root-cause of your issue. You are advised to go through each strategy and perform the verification accordingly.

Strategy	Implications
Ensure that you have enabled the remote update block in your design	If the remote update block is not enabled, you will not be able to use the remote update feature
Ensure that your user logic is according to the outline specified in the altremote_update megafunction user guide (Refer to the device handbook on how to enable the remote update block in your design)	Some of the interface might not work properly when you switch to other application images
Ensure that you assigned the right starting address for your application page. Refer to handbook and related application notes for more information on how to assign the right start address.	The device will not be able to load the appropriate image if the start address of the application is assigned incorrectly
Ensure that the start address of your application page is written properly to the remote update circuitry. Use the right param[2..0], assert write_param for one clock cycle and make sure the data on the data_in input bus is stable before write_param is asserted.	The device will not be able to load the appropriate application image if the start address of the application image is written incorrectly
Ensure that you trigger the reconfiguration input of altremote_update for at least one clock cycle. Refer to the handbook or user guide for related specification (if any) on reconfiguration input port of altremote_update megafunction	This ensures the device is able to detect the nCONFIG positive edge to initiate reconfiguration

The version of the Quartus II software that you were using when this issue was encountered

The FPGA part number that you were using when this issue was encountered

A screenshot of SignalTap II at the start address writing operation of the application image

Clock frequency supplied to the altremote_update megafunction

Specify your observations after performing the recommended debug strategies

You can also search the Community to ask and answer questions about the FPGAs and Programmable Solutions family of products.

High-Performance

Mid-Range

Power and Cost-Optimized

AI Development Tools

FPGA Design & Simulation Tools

Embedded Design Tools & Software

IP Development Tools

High-Performance

Mid-Range

Power and Cost-Optimized

Interfaces

Memory Controllers

Digital Signal Processing & AI

Soft Embedded Processors

Transceivers & Basic Functions

FPGA Development Tools

Embedded Tools

Add-On Development Tools

Design Hubs

Developer Centers

Training

FPGA Developer Site

Design Store

All FPGA Documentation

FPGA Configuration Troubleshooter

What is your configuration issue?

Products

High-Performance

Mid-Range

Power and Cost-Optimized

AI Development Tools

FPGA Design & Simulation Tools

Embedded Design Tools & Software

IP Development Tools

High-Performance

Mid-Range

Power and Cost-Optimized

Interfaces

Memory Controllers

Digital Signal Processing & AI

Soft Embedded Processors

Transceivers & Basic Functions

Solutions

Design

FPGA Development Tools

Embedded Tools

Add-On Development Tools

Design Hubs

Developer Centers

Training

FPGA Developer Site

Design Store

All FPGA Documentation

Support

About

Contact Us

FPGA Configuration Troubleshooter

What is your configuration issue?