A few hundred fridge monitors in the field, one of them rebooting at night, and no serial cable within reach. On an STM32F746G-DISCO running Zephyr, this is how the board captures its own crash, uploads it over Ethernet, and lets you read the decoded stack trace in a browser without touching the device.
The partition from Parts 1 and 2 protects the secure world from the non-secure one at run time. It does nothing about the two questions that decide whether a product is actually secure: who verified the code that set up that partition, and what stops the application from reading the keys the boot code used.
STM32H5 answers both in hardware, and the mechanism is not the one most engineers expect. It is not a permission bit. It is a counter that only goes up.
Part 1 described a partition that the hardware enforces. This part is about creating it, and the honest summary is that the difficulty is not in any individual register. It is that the same boundary has to be described three separate times, in three places that never check each other.
If you have spent twenty years in this field you have already built isolation without TrustZone: an MPU, a supervisor call layer, maybe a second MCU on the board holding the keys. TrustZone-M is worth understanding not because it does something you could not do before, but because it moves the isolation boundary from software you wrote to hardware you configure once, at a cost measured in a handful of cycles, not in an exception entry.
A generic AI assistant writes plausible STM32 code that does not build, flashes nothing, and invents register names. Skills fix that. Here is how to structure an STM32 project an agent can work in, and how to write your first SKILL.md.
Which security features does your STM32 product actually need? This walkthrough runs STRIDE on a battery sensor that reports over BLE or LoRaWAN, and matches each of the six threat types to an STM32 feature you can turn on. You end up with a reusable threat-to-feature checklist that works from classic F4 parts up to the Cortex-M33 families.
STM32 gives you several ways to protect flash: RDP, WRP, PCROP, HDP, the Firewall on some parts, and a product-state life cycle on the newest ones. They overlap, so they get mixed up. Each one blocks a different attack, and a protection that stops one attack often does nothing about another.
This article covers what each mechanism blocks and what it does not, how the set changed when STM32 moved to Cortex-M33, and how to combine them on a real product.
The details vary by family. Where something is family-specific, the family is named. This matters: STM32 security features are not uniform across the range, and assuming they are is how devices ship unprotected.
Ac6 introduces the Devicetree Manager for Zephyr, a CubeMX style configurator for Zephyr that covers all STM32 boards.
Ac6 announces Workbench for Zephyr, a free and open source VS Code extension for developing Zephyr RTOS applications on STM32.