6.6

How to update the secure/nonsecure memory mapping

In case of memory isolation for secure and nonsecure applications, the secure and nonsecure applications share

the same internal flash memory and embedded SRAMs.

The STM32CubeU5 firmware package provides default memory partitioning in the partition_<device>.h files

available under:

\Drivers\CMSIS\Device\ST\STM32U5xx\Include\Templates (see Section 4.2.1).

Any memory map partitioning change between secure and nonsecure applications requires the following updates

and alignments (without overlap between secure and nonsecure memory space and using secure and nonsecure

memory address aliases):

•

If SAU is enabled, nonsecure area update (internal flash memory and SRAMs) (see partition_stm32u5xx.h

file).

•

Secure and nonsecure linker files update to correctly locate the secure and nonsecure code and data.

•

Update the nonsecure address to jump to (in secure main.c and nonsecure reset handler in nonsecure

linker file)

•

Update the flash memory watermark option bytes (SEC_WMx_PSTRT/SEC_WMx_PEND) to define the

secure/non- secure flash memory areas (with STM32CubeProgrammer).

6.7

How to set up interrupts for secure and nonsecure applications

At MCU core level, all interrupts are set to secure at system reset. This default state is visible in the

partition_<device>.h files available under:

\Drivers\CMSIS\Device\ST\STM32U5xx\Include\Templates (see Section 4.2.1).

One of these template files is intended to be copied in the secure application for the selected device. This is to set

the interrupt line targets by modifying the partition_<device>.h file: either to target the secure (default) or

nonsecure application vector table. This insures that interrupts are set up when the application enters the secure

main().

6.8

Why does the system enter in SecureFault_Handler()?

SecureFault_Handler() is reachable if the SecureFault handler is enabled by the secure code with SCB-

>SHCSR |= SCB_SHCSR_SECUREFAULTENA_Msk;

Any jump to SecureFault_Handler() during the application execution is the result of a security violation

detected at IDAU/SAU level such as a fetch of a nonsecure application to secure address.

If the SecureFault handler is not enabled, the security violation is escalated to the HardFault handler.

6.9

Are there any links with standard peripheral libraries?

The STM32CubeU5 HAL and LL drivers are the replacement of the standard peripheral library:

•

The HAL drivers offer a higher abstraction level compared to the standard peripheral APIs. They focus on

the features that are common to the peripherals rather than the hardware. a set of user-friendly APIs allows

a higher abstraction level that in turn makes them easily portable from one product to another.

•

The LL drivers offer low-layer registers level APIs. They are organized in a simpler and clearer way

avoiding direct register accesses. LL drivers also include peripheral initialization APIs, which are more

optimized compared to what is offered by the SPL, while being functionally similar. Compared to HAL

drivers, these LL initialization APIs allow an easier migration from the SPL to the STM32CubeU5 LL

drivers, since each SPL API has its equivalent LL API.

6.10

Does the HAL layer take advantage of interrupts or DMA? How can this be

controlled?

Yes. The HAL layer supports three API programming models: polling, interrupt and DMA (with or without interrupt

generation).

6.11

How are the product/peripheral specific features managed?

The HAL drivers offer extended APIs, which are specific functions provided as add-ons to the common API to

support features available on some products/lines only.

UM2883

FAQ

UM2883 - Rev 4

page 23/30