10CL040YF484 Programming fails

Hi Suvarna,

thanks for clarification about MSEL1. Didn't notice jumper resistor option. As you are supplying B6 with 3.3V, MSEL can be connected to 3.3V. 2.5V should be accepted as well.

Having configuration correct, I wonder what causes failure of your board. I would probably try without C160-163 and D10/11 to be sure that they don't interfer with AS configuration load.  

Regarding 2.5 V switching regulator, I said I'd prefer LDO. it's exclusively loaded by VCCA and programming connector. Efficiency in normal operation is probably better for 3.3V supplied LDO. But your solution should work, too.

Regards
Frank

P.S.: I notice that Figure 99. Combining JTAG and AS Configuration Schemes also has 10 pF capacitors, but without additional series resistors.

Hi Survarna,
reviewing your schematic, I notice that it fails to set AS configuration mode due to floating MSEL1. For apparently intended mode 0010, MSEL1 has to be connected to 3.3V. FPGA actually reads mode 0000 (PS) and won't load AS flash. Volatile JTAG configuration should nevertheless work.

Regarding JTAG failure (programmer doesn't detect connected FPGA), you can focus on JTAG connection and FPGA power supply. All POR monitored voltages must be present and in range.

Isolation of GNDA pins through ferrite bead isn't complying with Altera pin connection guidelines but probably does no harm. I would also prefer a LDO for 2.5V PLL supply.

I believe that I last implemented separate AS programming ("ISP") connector 15 or 20 years ago. Since then we used JIC programming through JTAG connector.

I understand that failing and (at least partly) working boards share the same hardware design.

Regards
Frank

Dear Sir,

please see the attached images

Dear Sir,

please see my previous mail attached schematic and please see images attached . in working card DEVICE ID is coming and in bad card direct its telling JTAG error.

please see the attached images

VCCIO bank1 voltage is 3.3V only and VREF pins i am using them as i/o pins. 

MSEL setting  "0010" and nCE grounded with 10k resistor and connected to programmer 6th pin. with same download cable and same program i am loading in to good card and bad card. 

 TCK freq is 6MHZ waveform attached.

Dear Sir,

Please find the attached schematic in previous reply.

The cards in which JTAG error is coming in that TDO is not coming. in this card CONF_DONE pin always high and NCSO  is "LOW"    after programming  in AS mode  and NSTATUS is LOW. NCONFIG once program started its becoming LOWfor some time and then HIGHuntill proram and after Program over in AS mode.

and in working cards NSTATUS during Program LOW and after Program over it is HIGH. CONF_DONE is during Program LOW and after Program over it is HIGH. NCONFIG once program started its becoming LOW for some time and then HIGH untill proram and after Program over in AS mode.

Dear Sir,

Please find the attached schematic

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:

1. Scope VCCIO, VCCINT, and VCCA on the failing cards and compare against passing cards.


2. Scope TCK on the failing cards for noise or ringing.


3. Verify MSEL, nCE, and nCONFIG connections match exactly between passing and failing boards.


4. 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.