Skip to content

STM32H5: wolfIP NS application under wolfBoot (TZEN=1)#115

Open
dgarske wants to merge 1 commit into
wolfSSL:masterfrom
dgarske:stm32h5_tzen
Open

STM32H5: wolfIP NS application under wolfBoot (TZEN=1)#115
dgarske wants to merge 1 commit into
wolfSSL:masterfrom
dgarske:stm32h5_tzen

Conversation

@dgarske
Copy link
Copy Markdown
Member

@dgarske dgarske commented May 11, 2026

Summary

Make make TZEN=1 on the NUCLEO-H563ZI build the wolfIP echo server as a Non-Secure application launched by wolfBoot (BLXNS), instead of running the whole stack in Secure world. The earlier all-secure-app approach deadlocked the ETH DMA; the Non-Secure split matches the H5's product-state defaults (peripherals are NS by default, the ETH DMA master is NS+unprivileged) and lets the same wolfIP feature set that runs under TZEN=0 also run under TZEN=1.

Verified end-to-end on hardware: wolfBoot validates and BLXNSes into the signed wolfIP image, PHY link comes up, DHCP succeeds, ICMP responds in ~0.6 ms, and TCP echo on port 7 round-trips a payload.

Required matching wolfBoot patch

This depends on a corresponding wolfBoot HAL patch on the stm32tz branch of the wolfBoot repo: wolfSSL/wolfBoot#775

  • hal/stm32_tz.c hal_gtzc_init: cede SRAM2 to NS and clear MPCBB_PRIVCFGR_VCTR for SRAM2 + SRAM3. Reset default leaves them privileged-only, which silently blocks the NS+unprivileged ETH DMA and parks the channel on DMACSR.TBU / DMADSR.TPS=6. Also widen hal_tz_sau_init region 2 to 0x20040000-0x2009FFFF.
  • hal/stm32h5.c periph_unsecure: clear GPIOx_SECCFGR for A/B/C/D/G and enable the GPIOG clock. H5 product-state defaults every GPIO pin to secure-only, so without this the NS RMII pin mux silently no-ops.

Layout

0x0C000000 wolfBoot (Secure, ~376 KB)
0x08060000 wolfBoot 1024-byte image header
0x08060400 wolfIP NS vector table + .text (boot partition, 640 KB)
0x20040000 NS RAM (SRAM2+SRAM3, 384 KB)
0x20000000 wolfBoot RAM (SRAM1 secure alias 0x30000000)

wolfBoot's do_boot sets MSP_NS from app_offset[0] and BLXNSes to app_offset[1]. The NS app's Reset_Handler writes VTOR_NS = 0x08060400 first thing so NS exceptions vector correctly. After BLXNS the chip is left running on wolfBoot's 250 MHz PLL; the NS app reverts SYSCLK to HSI/2 = 32 MHz so the existing USART3 BRR and SysTick math from the TZEN=0 build keep working.

Build

WOLFBOOT_ROOT=$HOME/GitHub/wolfboot \
  make TZEN=1 CC=arm-none-eabi-gcc OBJCOPY=arm-none-eabi-objcopy
WOLFBOOT_ROOT=$HOME/GitHub/wolfboot make signed factory

Produces factory.bin = wolfboot.bin (padded to the boot-partition offset) + ECC256-signed NS app, ready for STM32_Programmer_CLI -w factory.bin 0x08000000. The IMAGE_HEADER_SIZE=1024 env wrapper is required (sign tool defaults to 256 for ECC256, which would place the vector table at the wrong offset). WOLFBOOT_ROOT defaults to ../wolfboot and is overridable.

@dgarske dgarske self-assigned this May 11, 2026
Copilot AI review requested due to automatic review settings May 11, 2026 17:19
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants