New Contributor
New ContributorHi 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
Regular ContributorHi 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:
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
New ContributorHi 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
Regular ContributorHi 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:
Regards,
Fakhrul
