About FPGA programming to MAX 10

Good detailed write-up — let me work through each of your three questions systematically.

1. What is the JBC programming flow for MAX 10, and where does "No SLD hub / No SLD node / Unrecognized device" indicate failure?

The JBC/JAM flow for MAX 10 uses the standard IEEE 1149.1 JTAG interface. The JTAG circuitry and ISP instructions for MAX 10 devices are compliant to the IEEE-1532-2002 programming specification. At a high level, the player executes these stages:

1. CHECK_IDCODE — Shift out the 32-bit IDCODE register via the IDCODE instruction and compare against the expected value embedded in the JBC file. The IDCODE instruction (binary 00 0000 0110) selects the IDCODE register and places it between TDI and TDO, allowing you to shift the IDCODE register out of the TDO pin serially. MAX 10 · Config/RSU Your log confirms this succeeds: Device #1 IDCODE is 031830DD, which matches the NOTE 'IDCODE' = '031830DD' in the JBC header — so the device is electrically reachable and the JTAG chain is intact at this point.



2. CONFIGURE (SRAM load) — The player issues the appropriate ISP instruction and streams the SRAM bitstream into the device CRAM via JTAG. Your log shows ~2.4 million DR bits shifted in ("configuring SRAM device(s)..."), which corresponds to loading a helper/configuration image into CRAM.



3. SLD hub / SLD node discovery — After the SRAM image is loaded and the device enters user mode, the player attempts to enumerate the Virtual JTAG (SLD) infrastructure inside the running design. You can use a custom JTAG controller to discover transactions necessary to enumerate all Virtual JTAG IP core instances from your design at runtime. All SLD nodes and the virtual JTAG registers that they contain are targeted by two Instruction Register values, USER0 and USER1. SLD_NODE Discovery and Enumeration The SLD hub contains the HUB IP Configuration Register and SLD_NODE_INFO register for each SLD node in the design. The HUB IP configuration register provides information needed to determine the dimensions of the USER1 DR chain. The SLD_NODE_INFO register is used to determine the address mapping for Virtual JTAG instances in your design. This register set is shifted out by issuing the HUB_INFO instruction. Issuing the HUB_INFO Instruction



4. ISP programming via Virtual JTAG — Once the SLD hub and node are found, the player communicates with the on-chip ISP logic (implemented in the helper SRAM image) through the Virtual JTAG path to erase and program the CFM.

The failure point is step 3. "No SLD hub" means the player issued the USER0/USER1 HUB_INFO instruction sequence after the SRAM load, but the response from TDO did not match the expected SLD hub signature. "No SLD node" follows immediately because without a hub, no nodes can be enumerated. "Unrecognized device / Exit code 6" is the player's terminal error when it cannot find the expected Virtual JTAG infrastructure.

The root cause is almost certainly that the SRAM image that was loaded does not contain the required SLD hub / Virtual JTAG helper logic that the POF-based JBC flow depends on. See question 2 for why.

2. Why does the JBC from a POF fail while the JBC from a SOF succeeds?

This is the key distinction. The two JBC files load fundamentally different SRAM images:

• JBC from SOF — The SRAM image IS your application design. When it loads and enters user mode, your design is running. If your application design happens to contain a Virtual JTAG / SLD hub instance (e.g., from Signal Tap, JTAG UART, or an explicit Virtual JTAG IP), the SLD hub discovery succeeds and the player can proceed. This is why the SOF-based JBC works in your case — your application design apparently contains SLD infrastructure.



• JBC from POF — When programming the internal flash (CFM), Quartus Prime Programmer normally loads a special helper design into CRAM first. The Quartus Prime Software Programmer configures a MAX 10 device with a helper design when programming a Programmer Object File (.pof) to the configuration flash memory. Why does programming an Intel® MAX® 10 device in multiple-device JTAG chain fail with "Error(209012): Operation failed"? This helper design is what provides the Virtual JTAG / SLD hub interface that the POF-programming JBC player uses to communicate with the on-chip flash programming logic. If the helper design does not load correctly, or if the SRAM image embedded in the POF-based JBC does not contain the expected SLD hub, the "No SLD hub" error results.

In your specific case, the most likely cause is one of the following:

1. The JBC was generated without "Enable real-time ISP" checked. You can work around programming problems by turning on "Enable real-time ISP to allow background programming when available" in the Quartus Prime Software Programmer, which avoids using the helper design. Why does programming an Intel® MAX® 10 device in multiple-device JTAG chain fail with "Error(209012): Operation failed"? Without real-time ISP, the standard POF programming flow relies on the helper design + SLD hub path, which is what is failing. You must select "Enable real-time ISP to allow background programming" prior to creating a JAM file to enable ISP clamp for the JAM STAPL flow. MAX 10 · Config/RSU



2. A known Quartus version issue. Due to a problem in Quartus Prime Software version 17.0, JAM/JBC files generated for MAX 10 devices do not contain the DO_REAL_TIME_ISP option. To perform real-time ISP programming on MAX 10 devices, use JAM/JBC files generated in version 16.1 to execute the DO_REAL_TIME_ISP option. This issue is fixed in version 17.1. MAX 10 · Config/RSU You are using Quartus Prime Lite 25.1, so this specific bug should not apply, but it illustrates that the DO_REAL_TIME_ISP flag in the JBC is critical.



3. The JBC was generated from a POF without the real-time ISP option, and the altera-stapl player is not invoking DO_REAL_TIME_ISP. Looking at your JBC header, the available actions include PROGRAM but there is no DO_REAL_TIME_ISP listed as an option — this is a strong indicator that the JBC was generated without "Enable real-time ISP" checked. The standard (non-real-time) POF programming path requires the helper design + SLD hub, which the altera-stapl/jamplayer implementation may not support correctly.

Recommended fix

1. Regenerate the JBC from the POF with "Enable real-time ISP to allow background programming when available" checked in Quartus Programmer before creating the JAM/JBC file. Add your target POF to the MAX 10 device in the Programmer. For MAX 10 devices, ensure the "Enable real-time ISP to allow background programming when available" option is selected. Then choose "Create JAM, JBC, SVF or ISC file" under the File menu, type a file name, and choose Jam STAPL Byte Code 2.0 (.jbc) from the File format list. Click OK. How do I program MAX® II, MAX® V, or Intel® MAX 10 devices with the real-time ISP feature using the quartus_jli command?



2. When invoking the player, pass the DO_REAL_TIME_ISP flag: For .jbc: quartus_jli -aPROGRAM --enable=DO_REAL_TIME_ISP .jbc MAX 10 · Config/RSU — or the equivalent for the altera-stapl player: jbi_22 -aprogram -ddo_real_time_isp=1 file_name.jbc MAX 10 · Config/RSU



3. Also note: always use the .pof with pin state information to create the .jam or .jbc files. MAX 10 · Config/RSU

One additional note on your circuit topology: you mention the SoM JTAG signals and the JTAG connector signals are wired together. This problem (JAM/JBC programming failure) is only seen when other FPGA devices are in a JTAG chain with MAX 10. The problem is due to incorrect formatting in Quartus Prime Software when converting the programming file to JBC or JAM file. As a workaround, check the option "Enable real-time ISP to allow background programming when available." MAX 10 · Config/RSU So enabling real-time ISP addresses both the SLD hub issue and any multi-device chain formatting issue simultaneously.