On 17 March 2026 Mogens Lund (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.
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/
tf-m@lists.trustedfirmware.org
-
Ronan GABOU -
Steven Friedman