Agilex 7 JTAG Config Fails at 1% on Board #2 (Error 18950 / CONF_DONE Low) - But Board #1 Works

Hello everyone,

I am currently bringing up custom boards featuring an Agilex 7 FPGA and a MAX10 system controller. Here is the situation:

Board #1 configures and works perfectly, but Board #2 fails to configure via JTAG, using the exact same `.sof` file, programmer, and physical setup.

Since Board #1 is fully functional, I can definitively rule out issues with the `.sof` file, Quartus project settings, and the core schematic design. This points directly to a hardware/assembly variance on Board #2.

The Symptoms on Board #2:

When attempting to program the `.sof` file via Quartus Programmer, the progress bar stack exactly at 1%. After a timeout, `CONF_DONE` remains low, and the programmer outputs the following specific errors:

- Error(18950): Device has stopped receiving configuration data

-Error(18944): CONF_DONE pin failed to go high in device 1. Make sure all communication cables are securely connected...

-Error(209012): Operation failed

System Environment:

* Quartus Version: Quartus Prime Pro 26.1

* FPGA OPN: `AGFA014R24B1E1V`

* JTAG Chain:** MAX10 (Device 0) -> Agilex 7 (Device 1)

Troubleshooting Performed So Far on the FAILING Board:

- JTAG Integrity is 100% Solid: I ran the JTAG Chain Debugger for 5,000 cycles with 0 errors. Auto-Detect works flawlessly and identifies the silicon accurately as `AGFA014R24(AR1|B|BR1)`.

Hardware Measurements (Physical Pins on #2 Board):

- nSTATUS before configuration: Verified High (1.8V) (And it does not go down to 0 during the programming attempt nor at the end)

- nCONFIG state: Verified High (1.8V) (And it does not go down to 0 during the programming attempt nor at the end)

- OSC_CLK_1: 100MHz clock is present and stable

- Power Supplies (LTMs): All primary rails seem to be up

My Questions:

1. Knowing that the failure happens exactly at 1% (Error 18950), nSTATUS and nCONFIG are high, and it's a known-good design, what specific hardware faults cause the SDM to freeze at this exact early stage without throwing an internal SDM error?

2. Is there a way to get more details about the error and know what is causing it?

Any insights or pointers on hardware edge cases that cause this specific behavior would be greatly appreciated. Thanks