MAX 10 – Sporadic configuration failure after firmware update

This is a multi-factor diagnostic scenario. Here are the specific MAX 10 requirements and known failure modes to check, ranked by likelihood of causing what you describe.

1. Known Errata — Intermittent Configuration Failure

MAX 10 production devices shipped prior to date code 1625 may experience intermittent configuration failures. MAX 10 Device Errata This affects all MAX 10 devices with date code prior to 1625; the planned fix applies to devices with date code 1625 or later. MAX 10 Device Errata However, even with a post-1625 device: if you select Fast POR delay or Slow POR delay, this may result in failure even if the device has a date code of 1625 or later. MAX 10 Device Errata

Action: Verify your device date code and confirm you are NOT using Fast or Slow POR delay mode in your Quartus project settings.

2. Power Supply Slew Rate / Brownout

The MAX 10 has a hard requirement on power supply ramp time during power-up: for single-supply devices (VCC_ONE/VCCA) and dual-supply devices (VCC, VCCINT, VCCD_PLL, VCCA, VCCA_ADC), the maximum ramp rate requirement (tRAMP) is 3 ms. MAX® 10 FPGA Configuration User Guide

There is an updated POR scheme to be aware of: using this updated scheme gives a single power-up scheme with no power-up sequencing requirements, and the maximum power supply rail ramp time is increased from 3 ms to 10 ms; the minimum power supply rail ramp time of 200 µs is now a recommendation rather than an absolute minimum. From Quartus Prime software version 16.0 onwards, the POR scheme option will be unavailable. MAX 10 Device Errata

A power-down or brownout event that violates the ramp rate during an active flash write is a strong candidate for flash corruption. If the supply collapses too quickly during CFM programming (e.g., a brief power dropout mid-erase or mid-program), the CFM sector could be left in an indeterminate state. Critically, if the interrupted write operation's address range overlaps with CFM0 (factory image) due to an address mapping error (see point 3 below), it can silently corrupt the factory image as well.

3. Flash Address Mapping — High-Risk for Factory Image Corruption

This is frequently the cause of factory image corruption when only the application image was intended to be updated. The address shown in the map file includes ICB settings, CFM and UFM, but the Altera On-Chip Flash IP can access CFM and UFM only. Hence, there is an address offset between the address shown in the map file and the Altera On-Chip Flash IP parameter window. AN 741: Remote System Upgrade for MAX 10 FPGA Devices over UART with the Nios II Processor

If your firmware computes CFM2 start/end addresses from the map file directly without applying this offset, it can write into the wrong sector — potentially into CFM0 (factory image area). Verify your address translation logic carefully against the On-Chip Flash IP parameter window values, not the raw map file addresses.

4. Fallback Configuration Option — Check "Configure from CFM0 Only"

Even if both images are physically intact, fallback can be silently disabled by a project option: when "Configure device from CFM0 only" is Enabled: the CONFIG_SEL pin setting is disabled, the device automatically loads image 0, and the device does not load image 1 if image 0 fails. When Disabled (the default): the device automatically loads the secondary image if the initial image fails. MAX® 10 FPGA Configuration User Guide

Confirm this option is set to Disable (default) in your factory image project's Device and Pin Options so fallback is active.

5. Dual Compressed Image — Compression Ratio Requirement

If you are using dual compressed image mode: the compression ratio for the configuration image should be at least 30% for the device to be able to store two configuration images. MAX® 10 FPGA Configuration User Guide Insufficient compression can result in the second image not fitting correctly in flash, leading to load failures.

Diagnostic Checklist Summary

• Check device date code — pre-1625 devices are errata-affected for intermittent config failure.
• Confirm POR delay mode is not set to Fast or Slow POR delay in Quartus project settings.
• Measure power supply ramp rate during field updates; ensure it does not violate tRAMP = 3 ms (or 10 ms under the updated POR scheme) on any rail during power cycling adjacent to a flash operation.
• Audit your On-Chip Flash IP address calculations — use the IP parameter window addresses, not raw map file addresses, to avoid writing into CFM0.
• Verify "Configure device from CFM0 only" is Disabled in your factory image Device and Pin Options.
• Verify compression ratio ≥ 30% if using dual compressed image mode.
• If using CONFIG_SEL to select images, in dual compressed images mode, you can use the CONFIG_SEL pin to select the configuration image MAX® 10 FPGA Configuration User Guide — confirm pin state at power-up matches your intended boot image.

The most common root cause for factory image corruption (as opposed to just application image corruption) in field update scenarios is the address-offset issue causing unintended writes into CFM0, combined with a power event during the operation. I'd start there alongside the date-code and POR mode checks.