Hello,
I’m going to apply and test this patch set and come back to you as soon as possible.
Ronan,
[Shape, rectangle Description automatically generated]
Ronan GABOU | Tel: +33 1 58 07 80 19 MDG / General Purpose Microcontroller Sub-Group / Wireless Business Line / Cellular
[cid:image002.png@01DCD0BB.EB49DB20]https://www.facebook.com/STMicroelectronics.NV/ [cid:image003.png@01DCD0BB.EB49DB20] https://twitter.com/st_world [cid:image004.png@01DCD0BB.EB49DB20] https://www.linkedin.com/company/stmicroelectronics/ [cid:image005.png@01DCD0BB.EB49DB20] https://www.instagram.com/stmicroelectronics.nv/ [cid:image006.png@01DCD0BB.EB49DB20] https://www.youtube.com/user/STonlineMedia ST online: www.st.com online: www.st.com
From: Steven Friedman friedman@ionq.co Sent: Monday, April 20, 2026 1:05 AM To: tf-m@lists.trustedfirmware.org Cc: mogens.lund@prevas.dk; Ronan GABOU Ronan.GABOU@st.com; nicola.mazzucato@arm.com Subject: [PATCH 00/20] platform: stm: STM32H563 TF-M support
You don't often get email from friedman@ionq.comailto:friedman@ionq.co. Learn why this is importanthttps://aka.ms/LearnAboutSenderIdentification On 17 March 2026 Mogens Lund (mogens.lund@prevas.dkmailto:mogens.lund@prevas.dk) asked on this list whether STM32H563 TF-M support was planned, and whether there was a defined path for upstreaming a clone-and-adapt of the existing STM32H573I-DK port. This patchset provides that support: it extends the shared platform/ext/target/stm/common/stm32h5xx/ code to cover STM32H563 alongside STM32H573 and adds a NUCLEO-H563ZI board port that builds and runs on real hardware today.
Twenty patches, internally organised into three groups that review independently:
Group A [01..13] Generic STM32H5xx improvements. Every patch in this group changes STM32H573 runtime behaviour (correctness fixes, defensive hardenings, chip-family additions applicable to both H563 and H573). No #ifdef guards.
Group B [14..19] STM32H563 chip-variant support. Four commits (14-17) are mechanical enablers -- linkage changes and defensive conditionals that are no-ops on H573 but required by group C. Two commits (18-19) are H563-only behaviour under #ifdef STM32H563xx; H573 is unaffected.
Group C [20] NUCLEO-H563ZI board port at platform/ext/target/stm/nucleo_h563zi/, structurally mirroring the existing platform/ext/target/stm/stm32h573i_dk/ port. Thirteen of nineteen files are verbatim copies from stm32h573i_dk with original headers preserved; five contain authored content (CMakeLists.txt, cpuarch.cmake, include/board.h, include/stm32hal.h, secure/low_level_device.c); one (cpuarch.cmake) is adapted from stm32h573i_dk with a one-word chip-identifier change. See the commit body for the full file-by-file provenance.
Group A patches ---------------
01 fix dual-bank flash page addressing 02 wait for HSI48 ready before RNG init 03 map fault vectors to proper handlers 04 improve Error_Handler debug spin 05 extend system-memory SAU region to cover UID (H573 also gains NS UID access; RM0481 section "Unique device ID register") 06 add SAU region for OCTOSPI1 XIP aperture 07 enable SRAMx clocks before MPCBB programming (RM0481 section "RCC_AHB2ENR" -- SRAM2EN / SRAM3EN default to 0 on reset) 08 allow NS access to I/DCACHE register interfaces 09 guard SysTick init in UART stdio driver 10 default CONFIG_TFM_ENABLE_CP10CP11 ON for stm32h573i_dk (matches platform/ext/target/adi/max32657/cpuarch.cmake precedent; docs/integration_guide/tfm_fpu_support.rst section "FPU support") 11 enable configurable fault handlers in boundary setup 12 lock Secure MPU configuration after setup 13 refresh SystemCoreClock before RNG_Init
Group B patches ---------------
14 expose mpu_init() for platform overrides (linkage only -- drops 'static'; no runtime change) 15 drop static from n_configured_regions (same rationale as 14) 16 skip scratch flash area when it is not defined (conditional on FLASH_AREA_SCRATCH_OFFSET; H573's flash_layout defines it so H573 behaviour is unchanged) 17 clear AIRCR.BFHFNMINS defensively in boundary setup (no-op on H573 because Reset_Handler's LOCKSVTAIRCR lock stuck; documented mechanism for parts where it did not) 18 skip LOCKSVTAIRCR check for H563 (#ifdef STM32H563xx -- parts with BOOTHDPL = 0x01 boot at HDPL1 so the lock write is silently ignored; self-retiring when production parts ship with BOOTHDPL = 0x00) 19 skip PKA / AES / SAES TZSC config on H563 (#ifdef STM32H563xx -- H563 has none of those peripherals)
Group C patch -------------
20 add NUCLEO-H563ZI board port
Dependency on STMicroelectronics' cmsis-device-h5 -------------------------------------------------
Group C compiles cleanly against the TF-M tree only after the STM32H563 CMSIS device header has been imported. The canonical source is
https://github.com/STMicroelectronics/cmsis-device-h5
at the latest stable tag (v1.5.0 at the time of writing). The required imports are:
1. Add platform/ext/target/stm/common/stm32h5xx/Device/Include/stm32h563xx.h copied verbatim from the cmsis-device-h5 repository above. 2. Extend platform/ext/target/stm/common/stm32h5xx/Device/Include/stm32h5xx.h with an #elif defined(STM32H563xx) branch that #includes "stm32h563xx.h", mirroring the existing #if defined(STM32H573xx) branch.
Neither change is included in this patchset because groups A and B touch zero H563-specific register symbols -- every patch tests only the STM32H563xx build macro. I would appreciate guidance from ST on whether they would like to handle the vendor import themselves (same mechanism as the existing stm32h573xx.h), or whether they would prefer a follow-up patch from me that does the import.
Testing -------
All 20 patches applied together and boot-tested on NUCLEO-H563ZI hardware with a Zephyr 4.4 NSPE (CONFIG_FPU=y, thumbv8m.main-none-eabihf): BL2 -> TF-M SPE at isolation level 2 -> Zephyr NSPE hands off cleanly, zero SecureFault / HardFault / MemManage / BusFault. NS FPU access works across the S/NS boundary via the SPM-level CP10/CP11 programming enabled by the nucleo_h563zi cpuarch.cmake.
I do not have an STM32H573I-DK board. Group A is expected to be strictly behaviour-improving on H573 (correctness fixes, defensive hardenings, plus patch 10 which enables a cmake knob that the stm32h573i_dk port today leaves off), but confirmation from ST or other H573 users during review would be welcome.
--
STEVEN FRIEDMAN SENIOR STAFF ENGINEER P: 301.298.7997x168 E: friedman@ionq.comailto:friedman@ionq.co W: www.ionq.cohttp://www.ionq.co/
