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.