Forum Discussion

vasakpal's avatar
vasakpal
Icon for New Contributor rankNew Contributor
18 days 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 boots back into the Factory image instead of the Application image.

Below is the design setup:

  • RSU IP instantiated and connected over SPI
  • Avalon‑MM master interface of RSU IP is exported to user logic
  • onchip_flash data interface is also exported and visible in the top level
  • Firmware performs erase/write/verify through the exported Avalon‑MM interface
  • Autoboot decision is based on a bit stored in UFM, read at startup

No external power cycle occurs during RSU (warm reconfiguration).

Below are the observations:

  • RSU programming via firmware completes without errors
  • MAX10 reconfigures after RSU
  • Cold boot works correctly
  • Programming the App image via JTAG works
  • Issue occurs only after warm RSU (no power cycle)

Autoboot selection is controlled via a bit stored in UFM. For this I have exported the AV-MM 

I have the below questions:

  1. Is it expected that RSU does not automatically re‑enter autoboot logic?
  2. After warm RSU, must user RTL explicitly regenerate a boot / autoboot event?
  3. Are there recommended MAX10 reference patterns for autoboot handling after RSU?

Thanks for any guidance or references.

 

3 Replies

  • FakhrulA_altera's avatar
    FakhrulA_altera
    Icon for Regular Contributor rankRegular Contributor
    4 days ago

    Hi Vasakpal,

    This behavior is expected with MAX 10 RSU. RSU itself does not run your “autoboot” logic. It only controls which image is loaded on the next reconfiguration.

    For a warm reconfiguration, the device will follow the CONFIG_SEL pin unless you explicitly enable overwrite in the RSU input register. The ru_config_sel bit only takes effect when ru_config_sel_overwrite = 1. 

    Recommended actions:

    • Before triggering reconfiguration, write ru_config_sel_overwrite = 1 and ru_config_sel = 1 (select Application), then assert RU_nCONFIG. Remote System Upgrade Input Register
    • If your flow relies on “Factory boots first, reads UFM, then triggers a second reconfig to Application”, you must still generate that second reconfig event in your RTL/firmware after the Factory image comes up. RSU will not do it automatically. Updating Image and Triggering Reconfiguration using UART
    • Also check the user watchdog timer. If enabled and not reset by the Application image soon enough, the device will revert to the Factory image.

    For reference patterns,  MAX 10 RSU lab and AN 741 show the intended “select image then trigger reconfiguration” sequence.

    Regards,
    Fakhrul

  • vasakpal's avatar
    vasakpal
    Icon for New Contributor rankNew Contributor
    3 days ago

    Hi Fakhrul,

    Thank you for your response and for sharing the documentation links. I can confirm that we are following the exact same firmware steps you mentioned in your first bullet. I believe the issue lies in the way we are generating the .pof files.

    According to the link “Updating Image and Triggering Reconfiguration using UART”, bullet #2, section 1.7.1.2 states:

    “Open the app2.rpd using any hex editor. In the hex editor, select the binary data block based on the start and end offset by referring to the .map file. The start and end offset for the 10M50 device is 0x12000 and 0xB9FFF respectively. Copy this block to a new file and save it in a different .rpd file. This new .rpd file contains application image 2 only.”

    We are currently not performing these steps, and this seems to be the missing piece in our .pof generation flow. I am not fully clear on how to apply this procedure. Should we create a blank .rpd file and paste the CFM1 block contents into it? Since our device is a 10M04, I assume we may need to extract and paste CFM1 binary data block similarly.

    I can see in or CFM1.rpd file that the block start address at 0x00008800 but the block ends at 0x00023000, which is way before compared to the above end address of CFM1 block which is 0x0002B7FF.

    Please suggest. If there is another document that explains these steps in more detail, I would appreciate it if you could share that as well.

    BR,

    -Vishal

    • FakhrulA_altera's avatar
      FakhrulA_altera
      Icon for Regular Contributor rankRegular Contributor
      2 days 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