Feature: Processors and MCUs
This works extremely well when an application is a few
hundred kilobytes or several megabytes. However, Edge AI changes this calculation. In an AI-enabled IoT node, executable code, neural-network
models and supporting data can occupy many megabytes, reserving equivalent secondary storage simply to stage an update becoming expensive. Multiple independently updatable images compound the problem. System architects therefore need to think carefully about whether AI models should form part of the main executable image, be handled as separately authenticated data images, or be staged through alternative storage such as an SD card. The bootloader architecture and Flash map are consequently
no longer details to leave until the end of a project. They are system-level design decisions that must be made early in the project.
TrustZone and Trusted Firmware-M Secure boot establishes that trusted software has been loaded, but security does not stop when booting finishes. Arm TrustZone for Cortex-M allows the address space
and peripherals to be divided into Secure and Non-Secure worlds. On PSOC Edge, the Cortex-M33 provides this security boundary, while the Cortex-M55 operates as a non-secure application processor. The Secure Processing Environment may be used to host
Arm’s Trusted Firmware-M (TF-M). TF-M turns the relatively low-level isolation provided by TrustZone into a practical secure-services environment. Services such as cryptography, protected storage, internal trusted storage and attestation can be kept within the secure domain and accessed from normal application software through Arm Platform Security Architecture (PSA) APIs. Infineon’s PSOC Edge TF-M implementation follows this
model. Edge Protect Bootloader authenticates the TF-M, M33 non-secure and M55 application images, then transfers control to TF-M. TF-M establishes the required protection boundaries and subsequently starts the M33 non-secure application. The distinction between the Secure Enclave and TF-M is
worth emphasising. The Secure Enclave is a physically isolated hardware RoT and is not user-programmable. TF-M is an OEM-programmable secure software environment executing on the TrustZone-enabled Cortex-M33. Together they provide defence in depth rather than duplicate functionality.
Security as a product requirement This degree of security may once have seemed excessive for an MCU, but regulatory expectations are changing. The EU Cyber Resilience Act is one example. The Act places greater emphasis on secure products, vulnerability management and the ability to distribute security updates during a product’s supported lifetime. Secure-boot-protected cryptographic keys, authenticated firmware updates and rollback prevention do not by
themselves make a product CRA-compliant. They do, however, provide important technical foundations for building a product that can maintain its security after deployment. This is another reason Flashless MCU architecture and
secure boot architecture are becoming closely linked: If executable code must reside in externally-accessible memory, authentication and confidentiality can no longer be an afterthought.
Development becomes a systems problem There is another unavoidable downside: all of this is considerably harder to configure, and presents a steep learning curve at the beginning of a project. The firmware for a modern Flashless MCU may consist of several interdependent projects; see Figure 7:
Figure 7: Multiple sub-projects make up one application Each may have its own linker configuration, memory
regions, signing process and generated binary. The memory map becomes particularly critical. External Flash partitions, internal SRAM banks, TrustZone boundaries, bootloader slots, secure storage and shared IPC buffers must all agree across several projects. A mistake may not produce a friendly linker error, but a device that simply stops halfway through an authenticated boot chain. For that reason, silicon vendors increasingly provide
complete reference applications for the boot architecture. These should be treated as architectural starting points rather than merely demonstration code. Getting the vendor’s complete secure boot chain working before replacing individual application components is generally much easier than constructing the chain from scratch. Configuration tooling is also becoming more important.
Arm’s CMSIS-Zone Utility provides a graphical description of the system processors, memories, peripherals, interrupts and security regions. Within this tool you can define execution zones and allocate resources to them. This description
www.electronicsworld.co.uk October 2026 23
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
