Forum Discussion

vasakpal's avatar
vasakpal
Icon for New Contributor rankNew Contributor
1 month ago

MAX10 RSU upgrade succeeds, but device boots Factory image instead of Application

Hello, I’m using Intel MAX10 Remote System Upgrade (RSU) with: CFM0 = Factory CFM1 = Application The firmware‑triggered RSU upgrade completes successfully, but after reconfiguration the device ...
Configuration
Core Logic
Programmable Logic Device
FakhrulA_altera's avatar
FakhrulA_altera
Icon for Regular Contributor rankRegular Contributor
1 month ago

Hi Vishal,

 

You’re correct, the 10M50 offsets are just examples. For your 10M04, use your project’s .map. In your map, CFM1 spans 0x00008800–0x0002B7FF (byte addresses).

Recommended procedure:

  • From the combined application .rpd, extract exactly the byte range 0x00008800–0x0002B7FF into a new “CFM1‑only” .rpd (contiguous data, no headers).
  • Program this file into On‑Chip Flash starting at 0x00008800 through 0x0002B7FF.
  • Set the Remote Update boot address to the Application start page (convert 0x00008800 to page units per the RSU IP guide), then trigger reconfiguration.

If your current CFM1.rpd ends at 0x00023000, it’s incomplete and will fail CRC, which explains the fallback to Factory after warm RSU.

References: see the Generating files for Remote System Upgrade,

.pof Generation through Convert Programming Files


Regards, 
Fakhrul

vasakpal's avatar
vasakpal
Icon for New Contributor rankNew Contributor
1 month ago

Hi Fakhrul,

Please disregard my earlier comments on the CFM1.rpd range. The combined .rpd shows CFM1 spanning from 0x00008800 to 0x0002B7F0 instead of 0x0002B7FF. My understanding is that this difference is acceptable because it’s just padding, correct?

Also, our current flow generates a .tar file that contains the .pof, and we use that package for performing Remote Upgrade through firmware.

I need to verify whether for the above step #7, if we can take the CFM1‑only .rpd, generate a .pof from it, and still use that for the upgrade process. If you have any additional thoughts or concerns, please let me know.

BR,

-Vishal

  • FakhrulA_altera's avatar
    FakhrulA_altera
    Icon for Regular Contributor rankRegular Contributor
    1 month ago

    Hi Vishal,
     

    Thanks for the update.

    The 0x0002B7F0 vs 0x0002B7FF difference is just trailing 0xFF padding. It’s acceptable as long as the flash beyond 0x0002B7F0 remains erased (0xFF). For safety and consistency, extract and program the full CFM1 range per your .map (0x00008800–0x0002B7FF, inclusive).

    For firmware‑driven RSU using On‑Chip Flash, please use a CFM1‑only .rpd as the payload (as in step #7). A .pof is a programmer container intended for JTAG/off‑board programming and is not suitable unless your firmware explicitly parses it. Recommended: keep your .tar but include the CFM1‑only .rpd for the RSU path (you may still ship a .pof separately for lab JTAG, if needed).


    Please:

    • Erase and program exactly 0x00008800–0x0002B7FF.
    • Verify after write.
    • Set the Remote Update boot address to the Application start page (convert 0x00008800 to page units per the RSU IP guide) before triggering warm reconfig.

    Regards,
    Fakhrul