Subject: Hitless Update Implementation Guidelines (AN904)

I'll address each of your three questions in turn.

1. Section 1.5 of AN904 — Quartus Prime Programmer for Hitless Update

Your interpretation is correct. AN 904 describes implementing the hitless update through the Quartus Prime Programmer or the Jam STAPL Byte-Code Player. AN 904: MAX 10 Hitless Update Implementation Guidelines The Quartus Prime Programmer path in that section is primarily a file generation and orchestration path, not a guarantee of glitch-free I/O during the update itself when used directly from the GUI.

To implement the hitless update through the Quartus Prime Programmer, you must create and execute a pin state information (.ips) file. AN 904: MAX 10 Hitless Update Implementation Guidelines The key point is that the MAX 10 hitless update in AN904 must be performed through external JTAG pins, AN 904: MAX 10 Hitless Update Implementation Guidelines and the MAX 10 device must be in user mode before performing the hitless update. AN 904: MAX 10 Hitless Update Implementation Guidelines If the device is not already in user mode (e.g., it is blank or freshly erased), the real-time ISP / hitless clamp mechanism will not engage correctly — which is a common source of confusion between "programming via Programmer GUI" and "true hitless update."

So yes — Section 1.5 is best understood as describing how to use the Programmer to generate the .pof + .ips → .jbc/.jam files that carry the hitless algorithm, not as a claim that clicking "Program" in the GUI alone achieves a hardware-glitch-free update.

2. JBC Hitless Update Failure — Generation and Execution Checklist

Here are the critical checkpoints based on the documented flow:

File generation:

• Always use the .pof with pin state information to create the .jam or .jbc files. AN 630: Real-Time ISP and ISP Clamp for Intel MAX Series Devices The pin state must be embedded in the .pof before conversion.


• The .jam or .jbc file contains all information required to program the ISP-capable device(s), including the programming algorithm and the hitless update mechanism — if you include the .ips file during file conversion. AN 904: MAX 10 Hitless Update Implementation Guidelines If the .ips was not included at conversion time, the clamp data will be absent from the .jbc.


• 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. AN 904: MAX 10 Hitless Update Implementation Guidelines

Known software 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. Why is my Intel® MAX® 10 device being erased and programmed in normal ISP mode even though I invoke the DO_REAL_TIME_ISP option using JAM/JBC files generated in Intel® Quartus® Prime Software version 17.0? Please confirm which Quartus version you used to generate the .jbc.


• There is also a separate known issue: programming MAX 10 with a JBC or JAM file may fail when other FPGA devices are in a JTAG chain with MAX 10, due to incorrect formatting in Quartus Prime Software when converting the programming file. The workaround is to check "Enable real-time ISP to allow background programming when available" before generating the JAM/JBC file. Why does Intel® MAX® 10 fail programming with JAM file?

Execution — ISP clamp and TAP sequencing:

• You can set the I/O pins to tri-state (default), high, or low states; or sample and sustain the existing pin state in the ISP clamp operation. AN 630: Real-Time ISP and ISP Clamp for Intel MAX Series Devices If your .ips specifies "sample and hold" but the signals are toggling at the moment of SAMPLE execution, the captured value will be incorrect.


• You need a steady-state signal because you cannot control the sample set-up time — it depends on the TCK frequency as well as the download cable and software. AN 630: Real-Time ISP and ISP Clamp for Intel MAX Series Devices


• The EXTEST instruction is then executed to clamp the I/O pins to the values loaded into the boundary-scan registers during SAMPLE/PRELOAD. AN 630: Real-Time ISP and ISP Clamp for Intel MAX Series Devices If the TAP is reset prematurely before EXTEST completes, the clamp is released early — this is the most common cause of I/O dropping mid-update.


• When the ISP clamp feature is used, the weak I/O pull-up resistors are disabled during programming even if the I/O is clamped to a tri-state value. AN 630: Real-Time ISP and ISP Clamp for Intel MAX Series Devices If your downstream logic depends on pull-ups during programming, this can cause apparent "drops."

Blank device edge case:

• When a MAX 10 FPGA is blank (new device, or UFM and CFM erased), the JAM player cannot program it successfully because the real-time ISP feature is turned on when the device is not in user mode. To fix this, use the JAM player command to disable the real-time ISP feature and program it again. Why Intel® MAX® 10 FPGA cannot be programmed with Jam player if it is blank? Since you mention the new image runs after a power cycle, this suggests the flash write itself succeeds but the clamp/reconfiguration handoff is failing — pointing to the TAP sequence or clamp release timing rather than the file content.

Jam Player execution command:

For real-time ISP with the .jbc and Jam STAPL Byte-Code Player, use: jbi_22 -aprogram -ddo_real_time_isp=1 file_name.jbc AN 630: Real-Time ISP and ISP Clamp for Intel MAX Series Devices Confirm this flag is being passed; omitting it will cause the player to fall back to normal ISP (tri-state, no clamp).

3. CFM0-Only (Partial) Hitless Update

All CFM in MAX 10 devices consist of three sectors — CFM0, CFM1, and CFM2 — except for the 10M02. MAX® 10 FPGA Configuration User Guide Your 10M08 and 10M25 both have all three CFM sectors.

The ISP clamp and boundary-scan mechanism itself is independent of which CFM sectors are being written — the clamp operates at the JTAG TAP level and holds I/Os stable regardless of the flash write scope. MAX 10 devices offer the hitless update feature, which provides the capability and flexibility to control the state of the I/O pins during the internal flash image update and reconfiguration. AN 904: MAX 10 Hitless Update Implementation Guidelines All I/O pins can remain stable without any disruption throughout the hitless update process. AN 904: MAX 10 Hitless Update Implementation Guidelines

However, the critical constraint is the reconfiguration trigger: after the flash write completes, the device must reconfigure from the updated image. In a typical Hitless Update setup, you must first perform a Remote System Update (RSU), which involves updating the agent device's Configuration Flash Memory (CFM) with either the factory image or an application image. This step must be completed before initiating the JTAG instructions required for the Hitless Update procedure. AN 963: MAX 10 Hitless Update Implementation Guidelines Using Internal JTAG Interface If you are writing only CFM0 and the device is configured to boot from CFM0, the reconfiguration after the write should pick up the new CFM0 image — but you need to ensure the boot source selection in your POF matches your intent.

For the internal JTAG approach (which avoids the external JTAG pin dependency), when the host controls the agent to perform a Hitless Update, a challenge arises after the CLAMP instruction is executed: the agent's I/O pins are clamped, preventing the host from driving further reconfiguration since access to the I/O pins is restricted. To overcome this, the agent MAX 10 device should include an RTL design module within its core that initiates the reconfiguration internally once the CLAMP instruction has been executed. AN 963: MAX 10 Hitless Update Implementation Guidelines Using Internal JTAG Interface

In summary: CFM0-only programming is supported within the hitless update framework, but verify your boot image selection and ensure the reconfiguration source is correctly set to CFM0 in your design.