Hi,
I’m currently working with the NXP RIOP evaluation board and have successfully completed the Getting Started guide and tested the pre-programmed FreeMASTER demo.
My next step is to rebuild the demo from source, flash it back to the board and verify that my complete build and flash pipeline works.
I checked the following documentation and sources:
Getting Started: GS-REMOTE-IO-PLATFORM
RIOP User Guide: UG10224
GitHub repository: nxp-appcodehub/rd-riop-demo
The GitHub repository contains the two projects
riop_M33LEADER_DEMO
riop_M7FOLLOWER_DEMO
and specifies the required SDK and tool versions, including the MIMXRT1189 SDK 25.09.00.
What is still not completely clear to me is how to get from these two projects to the same bootable firmware configuration that is delivered on the board.
Questions:
What is the recommended way to build the M33 and M7 projects? Do I simply import and build both projects separately in MCUXpresso, or is there a required build order or dependency between them? Can I also use the VS Code Extension?
How are the resulting M33 and M7 images programmed to the RIOP? Is the Secure Provisioning Tool the intended way to create and flash the complete application?
Is there an existing Secure Provisioning Tool configuration or example that shows how the two images are combined, including the correct memory layout and flash addresses?
How is image authentication handled for the RIOP demo? Is secure boot/signature verification enabled in the factory configuration, and is any key provisioning required when flashing a self-built version of the demo?
Is there a way to determine which version of rd-riop-demo is currently programmed on the board before overwriting it?
From the example code, it looks like the RT1189 Boot ROM starts the M33 application and the M33 then starts the M7 at 0x303C0000 using MCMGR. Is this the complete boot flow of the factory image, or is there an additional boot stage that is not part of the GitHub repository?
Is the original factory image available somewhere so that the board can be restored to its Out-of-Box state if necessary?
Is there also a command-line/headless build workflow available? In the longer term I would like to make the build reproducible and suitable for CI.
The Getting Started guide explains the Out-of-Box demo well, and the GitHub repository provides the sources, but I’m currently missing the connection between the two:
GitHub sources -> build M33/M7 -> create bootable image -> flash -> run the same demo
Maybe I overlooked the relevant section in UG10224 or another document.
Thank you!
Hi Shelly,
thank you very much for the detailed answer!
Best Regards
Marco
Dear @Embernard ,
Regarding your questions, please find the responses below:
1. The RIOP demo supports both MCUXpresso IDE and VS Code + MCUXpresso for VS Code. We recommend using VS Code. After importing the riop_M7FOLLOWER_DEMO and riop_M33LEADER_DEMO projects, it is recommended to build the M7 follower project first, followed by the M33 leader project. This is because the M33 project references the riop_M7FOLLOWER_DEMO.axf.o file generated by the M7 project as the multicore slave image.
2. Only the riop_M33LEADER_DEMO.axf file needs to be programmed into Flash using the Secure Provisioning Tool (SPT). Please refer to UG10224, Section 4.1.5 "Running the Demo Application". We recommend downloading and using the latest SPT v26.06. Please note that some configuration settings differ slightly from those shown in the user guide:
3. Please refer to UG10224 to create your own RIOP SPT workspace. On the SPT side, its main role is to generate a bootable RT1189 application image and program it into the device.
4. During development, we recommend using an unsigned/open configuration for functional validation and do not recommend programming eFuses or keys.
Programming fuses is an irreversible operation and should only be performed as part of a production security process after proper validation, such as through shadow registers. Whether to enable secure boot, image signing, or encryption should ultimately be determined by your production security requirements and SPT configuration.
5. If the current firmware does not expose version information through FreeMASTER variables, UART output, or version strings, it is not possible to reliably determine which version of the rd-riop-demo is currently running on the board. We recommend backing up the Flash content before overwriting it, or adding version information to your custom firmware.
6. The startup model implemented in the current project is that the RT1189 first boots the CM33 (M33 leader), and then the M33 starts the M7 follower through the Multicore/MCMGR framework. No additional boot stage is required.
7. If recovery is required, the most reliable method is to read back and save the existing Flash image before reprogramming. If no backup is available, the only option is to rebuild and reprogram the rd-riop-demo, which will restore the system to a functionally equivalent state.
8. Command-line workflows are supported. SPT internally invokes command-line tools such as OpenSSL and SPSDK to generate keys and build/write images. For more information, please refer to the following documentation:
As for how the two images are linked together, the key flow is as follows:
1.The demo is structured as two linked multicore projects
The RIOP demo repository contains two project directories:
riop_M33LEADER_DEMO/
riop_M7FOLLOWER_DEMO/ .
In the MCUXpresso multicore project model, the primary/leader project links to the secondary/follower project. When the primary project is built, the secondary project is built first, and the secondary output image is included/embedded into the primary image.
2.The M33 project is configured as the multicore master, and the M7 project as the slave
In riop_M33LEADER_DEMO/.cproject , the project defines __MULTICORE_MASTER and __MULTICORE_MASTER_SLAVE_M7SLAVE . Its multicore master configuration points to:
${workspace_loc:/riop_M7FOLLOWER_DEMO/Debug/riop_M7FOLLOWER_DEMO.axf.o} .
This means riop_M7FOLLOWER_DEMO.axf is first processed into .axf.o , and that object is then linked into the M33 leader image as a “Slave Object.”
The M7 project is configured as M7SLAVE / __MULTICORE_M7SLAVE , using the CM7 ITCM/DTCM memory regions.
3.The actual merge happens mainly during the link/post-build stage
The MCUXpresso multicore flow processes the secondary-core image, including shifting secondary-core sections before linking them into the complete multicore image.
Therefore, the final riop_M33LEADER_DEMO.axf is essentially the M33 leader ELF plus embedded M7 follower image data/sections , not a simple binary concatenation of two standalone AXF files.
4.At runtime, M33 starts M7
In riop_M33LEADER.c , the M7 boot address is defined as:
CORE1_BOOT_ADDRESS = 0x303C0000 , and CORE1_KICKOFF_ADDRESS = 0x0 .
In SystemInitHook() , the code calls Prepare_CM7(CORE1_KICKOFF_ADDRESS) , and later in main() it calls MCMGR_StartCore(kMCMGR_Core1, CORE1_BOOT_ADDRESS, ...) to start the secondary core.
So although the M7 image is embedded into the M33 leader AXF, M7 execution is still explicitly kicked off by M33 at runtime.
5.The bootable image still needs SPT processing
For RT1180, the documentation states that the device can boot only from CM33. The Secure Provisioning Tool is used to generate a bootable image with a boot header from the raw application image, and MCUXpresso output types include .axf .
So the usual flow is:
riop_M7FOLLOWER_DEMO.axf → processed into riop_M7FOLLOWER_DEMO.axf.o → linked into riop_M33LEADER_DEMO.axf → SPT uses the M33 leader AXF to generate the bootable flash image.
Best Regards,
Shelly