Forum Discussion

suvarna's avatar
suvarna
Icon for New Member rankNew Member
21 hours ago

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's avatar
    Farabi_Altera
    Icon for Regular Contributor rankRegular 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:





    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.