Playing with the STM32MP2: Comments news update

STMicroelectronics launched the STM32MP2 microprocessor family as an industrial application processor, pairing dual ARM Cortex-A35 cores with auxiliary Cortex-M33 and Cortex-M0+ processors, integrated graphics, a neural processing unit, and a five-gigabit SERDES block. While ST designed the silicon around a full Linux software distribution with U-Boot and ARM TrustZone environments, hardware developer Andrew Zonenberg demonstrated that the chip can be completely repurposed as an oversized bare-metal microcontroller, as detailed in serd.es's report. His investigation began in December 2025 before a responsible disclosure window for an undisclosed silicon security defect delayed publication until ST reviewed the vulnerability and released an official security advisory.

This technical breakdown examines how embedded developers can strip away vendor board support packages, software development kits, and external dynamic memory to run bare-metal C++ on the device. By running directly out of internal static RAM rather than routing complex high-speed DDR lines on multi-layer circuit boards, engineers can use the processor for real-time applications requiring low board-level bill-of-materials cost. The methodology shows firmware teams how to target the auxiliary Cortex-M33 core, configure on-die memory banks, and access hardware peripherals using standard open-source toolchains.

Playing with the STM32MP2: what actually changed

Traditional high-performance microcontrollers like the STM32H7 require massive pin counts to interface with external hardware like FPGAs over a Flexible Memory Controller bus. An STM32H7 FMC bus consumes more than thirty pins scattered across packages like the TFBGA240 and TFBGA216, making routing on four-layer batch fabrication circuit boards nearly impossible. Although parts like the H75x line offer 0.8 mm pitch packages, clock speeds drop from 550 MHz to 480 MHz, and the pin layout remains crowded. The STM32MP2 line fundamentally alters this balance by integrating a 5 Gbps SERDES block with a PIPE interface that can be multiplexed via register bits into either PCIe Generation 1 or 2 with one lane, or USB 3.

The silicon combines dual Cortex-A35 cores with an auxiliary Cortex-M33 and a Cortex-M0+, while retaining the familiar STM32 register layouts and peripherals. The architecture preserves identical hardware IP blocks for AES-GCM cryptography acceleration and the True Random Number Generator. This continuity allowed code bringup to proceed using standard upstream aarch64 and ARM g++ toolchains alongside binutils without relying on proprietary vendor hardware abstraction layers. Instead of treating the chip as a Linux board computer, the entire software footprint was stripped down to a flat first-stage boot loader executing from Exception Level 3 directly out of on-chip SRAM.

Playing with the STM32MP2: how it works

Hardware execution began on an official STM32MP257F-EV1 evaluation board by targeting the auxiliary Cortex-M33 core using JTAG register access. Moving from JTAG debugging to nonvolatile storage required understanding the boot ROM behavior, which maps on-chip SRAM across four distinct physical address ranges with varying security permissions. To boot without an external operating system, a dedicated flashing tool constructs an initial image containing the required first-stage boot loader headers. The firmware image is placed into nonvolatile flash at either primary offset 0x0000_0000 or fallback offset 0x0004_0000.

The boot ROM initializes the system in M33-TD mode, handing immediate execution privileges to the Cortex-M33 core within the secure domain. Code execution resides within the RETRAM boot alias located at memory address 0x0e08_0000, while the stack and global variables execute via the D-side bus alias at 0x3008_0000. Because these aliases reference the same physical memory, linker scripts must prevent address overlap so text sections at 0x0e08_4141 do not collide with data at 0x3008_4141. Once running, initialization code enables VDDIO1 through VDDIO4 monitors, un-gates backup SRAM, sets the SYSCFG register to claim video encoder RAM as general memory, unlocks secure access via the RISAB registers, and invalidates the L1 instruction and data caches.

Playing with the STM32MP2: why it matters

Routing high-speed external memories such as DDR4 or LPDDR on custom printed circuit boards dramatically increases manufacturing complexity, layer count, and overall bill-of-materials expense. By confining all execution to internal static RAM, including SYSRAM, SRAM1, SRAM2, backup SRAM, LPSRAM, and borrowed video encoder RAM, engineers can deploy the processor like a standard microcontroller. This architecture bypasses the complex layout requirements of parallel memory buses while delivering compute performance far beyond legacy microcontrollers.

The integrated SERDES block provides a streamlined alternative to high-pin-count parallel interfaces when connecting the microcontroller to peripheral FPGAs. Instead of routing thirty or more FMC lines across congested PCB layers, engineers can achieve memory mapping over just two differential pairs through PCIe. High-speed communication avoids proprietary, undocumented vendor cryptographic accelerators that often restrict custom firmware development. The presence of documented register interfaces for hardware encryption and system clocks allows development teams to build completely transparent, inspectable bare-metal systems without proprietary runtime bloat.

Playing with the STM32MP2: who is affected

Embedded systems architects who previously hit performance and routing ceilings with the STM32H7 series now have a viable hardware upgrade path. Engineers building custom instrumentation, high-speed acquisition platforms, or FPGA-accelerated controllers can eliminate complex parallel buses without switching to completely unfamiliar peripheral ecosystems. The ability to use standard STM32 register libraries like stm32-cpp means teams can reuse existing driver code for serial ports, cryptographic units, and clock trees without learning vendor-specific application processor toolkits.

Developers operating under strict security and audit standards also benefit from removing Linux, U-Boot, and vendor binary blobs from edge devices. Running deterministic event loops directly in hardware Exception Level 3 simplifies qualification for industrial equipment that cannot tolerate variable boot times or operating system maintenance overhead. Conversely, teams attempting this bare-metal path must navigate complex linker scripts, multi-aliased bus layouts, and manual register configuration across the power management and clock distribution subsystems.

Playing with the STM32MP2: what to watch

Following the resolution of the hardware security disclosure with ST, further technical disclosures will detail the exact nature of the silicon bug and its impact on secure boot architectures. ST's documentation updates and errata sheets will determine whether future silicon revisions alter the SRAM address aliases or change the behavior of the boot ROM. Developers should monitor official ST advisories regarding the boot sequence, memory protections, and register interfaces across the entire STM32MP2 production portfolio.

The next technical milestone involves bringing up the primary 64-bit ARM Cortex-A35 cores in bare-metal mode to manage the integrated PCIe controller. Establishing direct PCIe communication with external FPGAs over two differential pairs will demonstrate whether low-cost, four-layer PCBs can successfully run high-bandwidth AXI bridging without dynamic RAM. As bare-metal firmware libraries mature, the STM32MP2 could become a standard reference design for high-throughput embedded systems needing modern SERDES connectivity without operating system overhead.