Designing a bootloader for a single-core microcontroller is a well-understood exercise. At power-on, the core begins execution at a fixed reset vector, the bootloader runs hardware initialisation, verifies the application image, and transfers control. Multi-core microcontrollers change this entirely. Modern automotive MCUs like the Renesas RH850/U2A with six cores, the NXP S32K3 with three Cortex-M7 cores, the Infineon AURIX TC3xx with its TriCore cluster, require a bootloader that orchestrates multiple CPU cores, manages per-core firmware images independently, and maintains security properties across a fundamentally more complex execution environment.
The PBL and SBL Architecture
Multi-core bootloader design converges on a two-stage architecture: a Primary Bootloader running on a single designated primary core, and Secondary Bootloaders on each additional core after the PBL releases them from reset. At power-on, only Core 0 begins execution; secondary cores are held in reset by hardware. The PBL initialises the clock system, memory controllers, external flash interfaces, and hardware security peripherals. It then validates each core's application image, verifying signature and integrity, before releasing that core from reset. This sequencing ensures that no secondary core ever executes unverified code.
Per-Core Image Management
Each core's firmware is best treated as an independently managed artifact with its own version number, signature, and update sequence. Per-core image management requires independent flash storage regions for each core's firmware, separate integrity verification applying the same signature scheme to each image independently, independent version tracking with per-core rollback counters, and independent A/B partition slots enabling one core's firmware to be updated while other cores continue running unaffected.
This independence is important when different cores run firmware developed by different teams or at different update cadences. A safety-critical application on Core 0 may update rarely while a communication stack on Core 1 updates monthly. Per-core image management allows this differential cadence without forcing synchronised releases.
Inter-Core Synchronisation During Firmware Update
Updating firmware on one core while other cores continue running requires careful synchronisation. The most common scenario is updating a secondary core's firmware via UDS flashing through the primary core. The primary core receives the UDS RequestDownload service, buffers incoming data, and writes the new image to the target secondary core's inactive flash slot while the secondary core continues executing its current firmware. When transfer completes and the image is verified, the primary core signals the secondary core to restart into the new firmware through an inter-core interrupt or shared memory flag. The secondary core's SBL performs its own independent image verification before handing control to the new application.
Multi-Core Secure Boot Considerations
The PBL's public verification key is the root of trust for the entire system, stored in hardware-protected memory that no application on any core can modify. The PBL's own integrity must be verified by an on-chip ROM boot sequence before the PBL executes, using device-fused root keys that establish hardware-rooted trust. Anti-rollback counters must be maintained per core independently — an attacker who compromises one core's image should not be able to manipulate a shared rollback counter to downgrade another core's firmware.
Implementing Multi-Core Bootloader with RAPIDSEA
RAPIDSEA's bootloader suite supports PBL-plus-SBL multi-core architecture for Renesas RH850/U2A, NXP S32K3, and Infineon AURIX TC3xx MCU families. The PBL handles hardware initialisation, multi-core clock and memory controller setup, per-core image verification using ECDSA or RSA, and sequential secondary core release after verification. Per-core A/B partition flash layout is configurable through the Flint IDE bootloader configurator. UDS-based multi-core programming is supported through a single UDS server on the primary core with logical routing of TransferData payloads to the appropriate secondary core's flash slot.
Conclusion
Multi-core bootloader design demands careful attention to startup sequencing, per-core image independence, inter-core synchronisation during updates, and a secure boot trust chain spanning all cores. RAPIDSEA's multi-core bootloader implementation provides a production-validated foundation, enabling embedded teams to deploy secure, updatable multi-core ECU firmware without building PBL-SBL architecture from first principles.
Ready to design your multi-core bootloader? Connect with us to request an evaluation build or book a technical demo.