Forum Discussion
10CL040YF484 Programming fails
- 1st Vendor Batch (Date Code: 2525):
- First Test (3 FPGAs):
- Card 1: ISP and JTAG programming successful; functioning correctly.
- Card 2: Programmed in ISP mode, but fails to execute and returns a JTAG error. Replacing the FPGA on this board with another one resulted in the same issue. -
- Second Test (3 FPGAs):
- Cards 3 & 4: ISP and JTAG programming successful; functioning correctly.
- Card 5: ISP and JTAG programming successful, but the device is not functioning correctly, and most pins are not working as required.
- Mouser Batch (Date Code: 2619):
- Third Test (2 FPGAs):
- Card 6: ISP and JTAG programming successful, but the device fails to function properly, with most pins not meeting requirements.
- Card 7: ISP programming successful, but returns a JTAG error and fails to execute.
Based on these outcomes, could you please help us identify where the problem lies?
1 Reply
- Farabi_Altera
Regular Contributor
This is a useful dataset — you have two distinct failure modes across two vendor batches, which actually helps narrow down the root causes. Let me break them down.
Failure Mode A — ISP programs successfully but JTAG errors / device fails to execute (Cards 2 & 7)
The most likely culprit here is a board-level JTAG signal integrity or pin connection issue, not a bad FPGA. A few things to check:
- JTAG pin noise or floating state: Noise on the JTAG pins during configuration, user mode, or power-up can cause the device to go into an undefined state or mode. Altera Cyclone 10 LP Device Design Guidelines Verify TCK, TMS, TDI, and TDO are clean on these specific boards with a scope.
- JTAG takes priority: Because JTAG configuration takes precedence over all other configuration methods, the JTAG pins should not be left floating or toggling during configuration if you do not use the JTAG interface. Altera Cyclone 10 LP Device Design Guidelines If TCK is picking up noise on those two boards, it can interfere with the non-JTAG configuration flow.
- TDO connection: TDO is a dedicated JTAG test data output pin. If the TDO pin is not used, leave this pin unconnected. Cyclone 10 LP Device Family Pin Connection Guidelines Check that TDO is not inadvertently shorted or loaded on Cards 2 and 7.
- nCE pin: You may receive a CONF_DONE failure if the nCE pin of the device is not connected to GND. For successful JTAG programming of a device chain, all nCE pins must be connected to GND. Why do I receive the error 'CONF_DONE pin failed to go high in device X' when I try to JTAG configure my Intel® FPGA using the Intel® Quartus® Prime Software and a download cable? Confirm nCE is properly grounded on those boards.
- MSEL pins: JTAG configuration is always available, regardless of the MSEL settings. Altera Cyclone 10 LP Device Design Guidelines However, the MSEL pins must be connected to select the configuration scheme — do not leave them floating. Altera Cyclone 10 LP Device Design Guidelines If MSEL is floating on those boards, behavior will be unpredictable. In Cyclone 10 LP devices, you must hardwire MSEL pins to VCCA (for logic high) or GND (for logic low). Which voltage should I use for MSEL pins to drive a logic high in Intel® Cyclone® 10 LP devices?
- AS mode + JTAG interaction: If your MSEL pins are set to AS mode, note that the ACTIVE_DISENGAGE instruction is required before JTAG programming regardless of the current state of the Cyclone 10 LP device if the MSEL pins are set to an AS configuration scheme. Cyclone 10 LP Core Fabric and General Purpose I/Os Handbook Also, if the MSEL pins are set to AS mode, the Cyclone 10 LP device does not transmit a DCLK signal when JTAG configuration takes place. Cyclone 10 LP Core Fabric and General Purpose I/Os Handbook
The fact that swapping the FPGA on Card 2 reproduced the same failure strongly points to a board-level issue on that specific card, not a device defect.
Failure Mode B — ISP and JTAG program successfully but most pins not functioning (Cards 5 & 6)
This pattern — programming succeeds but I/O behavior is wrong — typically points to power supply or I/O bank voltage issues rather than a programming problem.
- VCCIO levels: Cyclone 10 LP devices support a wide range of industry I/O standards. The device output pins do not meet the I/O standard specifications if the VCCIO level is out of the recommended operating range for the I/O standard. Altera Cyclone 10 LP Device Design Guidelines Measure VCCIO on each I/O bank on Cards 5 and 6 — a marginal or incorrect VCCIO rail is a very common cause of "pins not working" after successful configuration.
- GPIO tri-stated until configured: All Cyclone 10 LP GPIO pins are tri-stated until the device is configured and the configuration pins drive out. Altera Cyclone 10 LP Device Design Guidelines If CONF_DONE is not asserting properly, the device may appear configured but GPIOs remain tri-stated.
- VCCINT supply: VCCINT pins are the internal logic array voltage supply pins. All VCCINT pins must be connected to either a 1.0 V supply or a 1.2 V supply. Cyclone 10 LP devices with VCCINT 1.0 V and Cyclone 10 LP devices with VCCINT 1.2 V have different ordering codes. Cyclone 10 LP Device Family Pin Connection Guidelines Confirm you are supplying the correct VCCINT for your specific ordering code variant.
- CRC error detection note: CRC error detection is only supported in Cyclone 10 LP devices with VCCINT 1.2 V, and not in Cyclone 10 LP devices with VCCINT 1.0 V. Cyclone 10 LP Device Family Pin Connection Guidelines If you are relying on CRC error detection and running a 1.0 V core variant, that could mask configuration integrity issues.
Cross-batch observation
Both failure modes appear across both vendor batches (2525 and 2619), which argues against a batch/lot quality issue and strongly suggests board-level variation — likely marginal power rails, JTAG signal integrity differences, or MSEL/nCE wiring inconsistencies between individual cards. I'd recommend:
- Scope VCCIO, VCCINT, and VCCA on the failing cards and compare against passing cards.
- Scope TCK on the failing cards for noise or ringing.
- Verify MSEL, nCE, and nCONFIG connections match exactly between passing and failing boards.
- Check CONF_DONE assertion timing after programming completes on the failing cards.
If you can share the schematic or scope captures from a failing vs. passing card, that would help narrow it down further.