search.noResults

search.searching

saml.title
dataCollection.invalidEmail
note.createNoteMessage

search.noResults

search.searching

orderForm.title

orderForm.productCode
orderForm.description
orderForm.quantity
orderForm.itemPrice
orderForm.price
orderForm.totalPrice
orderForm.deliveryDetails.billingAddress
orderForm.deliveryDetails.deliveryAddress
orderForm.noItems
Feature: Processors and MCUs


The bootloader authenticates the image, copies it into SRAM


and transfers control to the loaded code. This consumes SRAM but provides much higher and more deterministic execution performance. In practice, real products are likely to mix the two approaches. Boot and frequently executed performance-critical routines may reside in SRAM, while less critical code or large read-only resources remain in external memory. Security complicates matters further. External Flash should


generally be considered physically accessible, so code must be stored, encrypted and decrypted by hardware as it is fetched, or, if loading into SRAM, it must be copied, authenticated and decrypted during boot.


Booting is no longer a jump to main() Perhaps the biggest architectural change is the boot process. A traditional MCU might perform as shown in Figure 4:


This chain loading is fundamental to modern secure boot.


Each trusted stage authenticates the next before permitting it to execute.


MCUboot becomes second-stage bootloader A notable feature of this new generation of devices is the adoption of MCUboot as the foundation for a second- stage bootloader (BL2), customised to use vendor-specific features. MCUboot is an open-source secure bootloader framework


originally designed for 32-bit microcontrollers. It provides a standardised image format and mechanisms for authenticated firmware installation and update. Infineon’s Edge Protect Bootloader (EPB) is based on


Figure 4: Traditional boot process With a modern Flashless device you may need several stages


of authentication. PSOC Edge provides an excellent example. Its first execution


environment is a dedicated Secure Enclave. The enclave contains two Cortex-M0+ processors operating in lockstep. It has dedicated ROM and SRAM that can’t be accessed by the application processors. The Secure Enclave forms the hardware Root of Trust


(RoT) and executes first after reset. Its immutable firmware authenticates the next stages of the boot process. The overall boot chain consists of the Secure Enclave boot and Extended Boot, before reaching OEM-controlled software. This may be the application or Infineon’s Edge Protect Bootloader, which is a custom version of the MCUboot project. A typical secure PSOC Edge configuration can therefore be viewed as shown in Figure 5:


MCUboot. Extended Boot can authenticate and launch EPB, which then extends the chain of trust to the remaining OEM images. Infineon supports authentication of up to five images through this mechanism and hardens EPB against physical attacks using MCUboot’s Fault Injection Hardening library. ST takes a similar approach with the STM32N6. Its


OEMuRoT (OEM updatable Root of Trust) is MCUboot- based, but integrated with the STM32N6 BootROM, security configuration, external-memory architecture and provisioning tools. This illustrates an important distinction: MCUboot


provides the framework and the semiconductor manufacturer provides the integration and custom adaptation. Among the important MCUboot capabilities are


authenticated and signed images, encrypted update images, multiple firmware images, rollback protection and several firmware installation strategies. MCUboot can, for example, decrypt encrypted firmware whilst transferring it from a secondary slot into the primary installation slot. It also supports overwrite and swap-based update strategies. Swap enables a particularly useful feature: a new firmware version can be booted on a trial basis and subsequently confirmed by the application. If it fails before confirmation, the system can revert to the previous working version. These facilities turn the bootloader into a firmware


lifecycle manager rather than simply a piece of code that jumps to an application.


The secondary-slot problem There is, however, a cost. Many MCUboot configurations use primary and secondary image; see Figure 6:


Figure 5: Secure multicore boot path 22 October 2026 www.electronicsworld.co.uk


Figure 6: Flash-based bootloader requires equal size execution and candidate slots


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44