UM2883

User manual

Getting started with STM32CubeU5 for STM32U5 Series

Introduction
STM32Cube is an STMicroelectronics original initiative to significantly improve designer's productivity by reducing development
effort, time, and cost. STM32Cube covers the whole STM32 portfolio.
STM32Cube includes:
• A set of user-friendly software development tools to cover project development from conception to realization, among which
are:
– STM32CubeMX, a graphical software configuration tool that allows the automatic generation of C initialization code
using graphical wizards
– STM32CubeIDE, an all-in-one development tool with peripheral configuration, code generation, code compilation, and
debug features
– STM32CubeProgrammer (STM32CubeProg), a programming tool available in graphical and command-line versions
– STM32CubeMonitor (STM32CubeMonitor, STM32CubeMonPwr, STM32CubeMonRF, STM32CubeMonUCPD
powerful monitoring tools to fine-tune the behavior and performance of STM32 applications in real-time
• STM32CubeU5 comprehensive embedded-software platforms specific to STM32U5 Series microcontrollers), which
include:
– STM32Cube hardware abstraction layer (HAL), ensuring maximized portability across the STM32 portfolio
– STM32Cube low-layer APIs, ensuring the best performance and footprints with a high degree of user control over
hardware
– A consistent set of middleware components such as FAT file system, RTOS, USB Host and Device, Touch library, and
Graphics
– All embedded software utilities with full sets of peripheral and applicative examples
• STM32Cube Expansion packages, which contain embedded software components that complement the functionalities of
the STM32Cube MCU and MPU packages with:
– Middleware extensions and applicative layers
– Examples running on some specific STMicroelectronics development boards
This user manual describes how to get started with the STM32CubeU5 MCU package.
Section 2 describes the main features of the STM32CubeU5 MCU package. Section 3 and Section 4 provide an overview of the
STM32CubeU5 architecture and MCU package structure.

UM2883 - Rev 1 - June 2021 www.st.com

For further information contact your local STMicroelectronics sales office.
UM2883
General information

1 General information

The STM32Cube MCU package runs on STM32 32-bit microcontrollers based on the Arm® Cortex®-M33
processor with Arm® TrustZone® and FPU.
Note: Arm and TrustZone are registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.

UM2883 - Rev 1 page 2/31

UM2883
STM32CubeU5 main features

2 STM32CubeU5 main features

The STM32CubeU5 MCU package runs on STM32 32-bit microcontrollers based on the Arm® Cortex®-M33
processor with Arm® TrustZone® and FPU.
The STM32CubeU5 gathers, in a single package, all the generic embedded software components required to
develop an application for the STM32U5 Series microcontrollers. In line with the STM32Cube initiative, this set
of components is highly portable, not only within the STM32U5 Series microcontrollers but also to other STM32
series.
The STM32CubeU5 is fully compatible with the STM32CubeMX code generator for generating initialization code.
The package includes low-layer (LL) and hardware abstraction layer (HAL) APIs that cover the microcontroller
hardware, together with an extensive set of examples running on STMicroelectronics boards. The HAL and LL
APIs are available in open-source BSD license for user convenience.
The STM32CubeU5 MCU package also contains a comprehensive middleware components constructed around
Microsoft® Azure® RTOS middleware and other in-house and open source stacks, with the corresponding
examples.
They come with free user-friendly license terms:
• Integrated and full featured RTOS: ThreadX
• CMSIS-RTOS implementation with ThreadX
• USB Host and Device stacks coming with many classes: USBX
• Advanced file system and Flash translation layer: FileX / LevelX
• Industrial grade networking stack: optimized for performance coming with many IoT protocols: NetX Duo
• USB PD library
• Open bootloader
• Arm Trusted Firmware-M (TF-M) integration solution
• MCU boot
• mbed-crypto libraries
• ST network library
• STMTouch touch sensing library solution.
Several applications and demonstrations implementing all these middleware components are also provided in the
STM32CubeU5 MCU package.
The STM32CubeU5 MCU package component layout is illustrated in Figure 1.

UM2883 - Rev 1 page 3/31

UM2883
STM32CubeU5 main features

Figure 1. STM32CubeU5 MCU package components

UM2883 - Rev 1 page 4/31

UM2883
STM32CubeU5 architecture overview

3 STM32CubeU5 architecture overview

The STM32CubeU5 MCU package solution is built around three independent levels that easily interact as
described in Figure 2.

Figure 2. STM32CubeU5 MCU package architecture

Level 2 Evaluation board and Discovery kit demonstration

Applications

Level 1
Library and protocol based components
(for example FS, RTOS™, USB PD)

Examples

Level 0 BSP drivers

Hardware abstraction layer (HAL)

Core drivers (optional) Low-layer (LL)

HAL

3.1 Level 0
This level is divided into three sub-layers:
• Board support package (BSP)
• Hardware abstraction layer (HAL)
– HAL peripheral drivers
– Low-layer drivers
• Basic peripheral usage examples

3.1.1 Board support package (BSP)

This layer offers a set of APIs relative to the hardware components in the hardware boards (such as LCD, Audio,
microSD™ and MEMS drivers). It is composed of two parts:
• Component
This is the driver relative to the external device on the board and not to the STM32. The component driver
provides specific APIs to the BSP driver external components and could be portable on any other board.

UM2883 - Rev 1 page 5/31

UM2883
Level 1

• BSP driver
It allows linking the component drivers to a specific board and provides a set of user-friendly APIs. The API
naming rule is BSP_FUNCT_Action().
Example: BSP_LED_Init(), BSP_LED_On()
The BSP is based on a modular architecture allowing an easy porting on any hardware by just implementing the
low-level routines.

3.1.2 Hardware abstraction layer (HAL) and low-layer (LL)

The STM32CubeU5 HAL and LL are complementary and cover a wide range of applications requirements:
• The HAL drivers offer high-level function-oriented highly-portable APIs. They hide the MCU and peripheral
complexity to end user.
The HAL drivers provide generic multi-instance feature-oriented APIs which simplify user application
implementation by providing ready to use processes. As example, for the communication peripherals (I2S,
UART, and others), it provides APIs allowing initializing and configuring the peripheral, managing data
transfer based on polling, interrupt or DMA process, and handling communication errors that may raise
during communication. The HAL driver APIs are split in two categories:
– Generic APIs which provides common and generic functions to all the STM32 Series
– Extension APIs which provide specific and customized functions for a specific family or a specific part
number.
• The low-layer APIs provide low-level APIs at register level, with better optimization but less portability. They
require a deep knowledge of MCU and peripheral specifications.
The LL drivers are designed to offer a fast light-weight expert-oriented layer which is closer to the hardware
than the HAL. Contrary to the HAL, LL APIs are not provided for peripherals where optimized access is not a
key feature, or for those requiring heavy software configuration and/or complex upper-level stack.
The LL drivers feature:
– A set of functions to initialize peripheral main features according to the parameters specified in data
structures
– A set of functions used to fill initialization data structures with the reset values corresponding to each
field
– Function for peripheral de-initialization (peripheral registers restored to their default values)
– A set of inline functions for direct and atomic register access
– Full independence from HAL and capability to be used in standalone mode (without HAL drivers)
– Full coverage of the supported peripheral features

3.1.3 Basic peripheral usage examples

This layer encloses the examples built over the STM32 peripherals using only the HAL and BSP resources.

3.2 Level 1
This level is divided into two sub-layers:
• Middleware components
• Examples based on the middleware components

3.2.1 Middleware components

The middleware is a set of libraries constructed around Microsoft® Azure® RTOS middleware and other in-house
(STMTouch, OpenBL..) and open source (TF-M, Mbed Crypto..). All are integrated and customized for STM32
MCU devices and enriched with corresponding application examples based on STM32 evaluation boards.
Horizontal interactions between the components of this layer is simply done by calling the feature APIs while
the vertical interaction with the low-layer drivers is done through specific callbacks and static macros implemented
in the library system call interface.
The main features of each middleware component are as follows:

UM2883 - Rev 1 page 6/31

UM2883
Level 1

• ThreadX:
– A real-time operating system (RTOS), designed for embedded systems with two functional modes:
– Common mode: common RTOS functionalities such as thread management and synchronization,
memory pool management, messaging, and event handling
– Module mode: an advanced usage mode that allows loading and unloading of pre-linked ThreadX
modules on-the-fly through a module manager.
• NetX duo
– Industrial grade networking stack: optimized for performance coming with many IoT protocols.
• FileX / levelX
– Advanced Flash file system (FS) / Flash translation layer (FTL): fully featured to support NAND/NOR
Flash memories
• USBX
– USB Host and Device stacks coming with many classes
• USB PD Device and Core libraries
– new USB type C power delivery service. Implementing a dedicated protocol for the management
of power management in this evolution of the USB.org specification. (Refer to http://www.usb.org/
developers/powerdelivery/ for more details)
– PD3 specifications (support of source / sink / dual role)
– Fast role swap
– Dead battery
– Use of configuration files to change the core and the library configuration without changing the library
code (read only)
– RTOS and standalone operation.
– Link with low-level driver through an abstraction layer using the configuration file to avoid any
dependency between the Library and the low-level drivers.
• Open bootloader
– provides an open source bootloader with exactly the same features as STM32 system bootloader and
with the same tools used for system bootloader
• Arm trusted firmware-M (TF-M)
– Reference implementation of the Arm platform security architecture (PSA) for TrustZone
– Secure services are:
◦ Secure storage service
◦ Attestation
◦ Crypto service
◦ TF-M audit log
◦ Platform service
Note: An example of TF-M application is available in the STM32CubeU5 firmware package under
\Projects\B-U585I-IOT02A\Applications\TFM.
• MCU boot
• mbed-crypto
– Open source cryptography library that supports a wide range of cryptographic operations, including:
◦ Key management
◦ Hashing
◦ Symmetric cryptography
◦ Asymmetric cryptography
◦ Message authentication (MAC)
◦ Key generation and derivation
◦ Authenticated encryption with associated data (AEAD).

UM2883 - Rev 1 page 7/31

UM2883
Level 2

• Network Library
– provides network services on STM32 devices. It
– provides a socket API (BSD like style) with support of secure or non secure connection and an API to
control the lifecycle of the network adapters.
– Three classes of network adapters are supported WIFI, Ethernet and Cellular. Different WIFI modules
are supported from third party vendors.
• STM32 Touch sensing library:
– Robust STMTouch capacitive touch sensing solution supporting proximity, touchkey, linear and rotary
touch sensors. It is based a proven surface charge transfer acquisition principle.

3.2.2 Examples based on the middleware components

Each middleware component comes with one or more examples (called also applications) showing how to use it.
Integration examples that use several middleware components are provided as well.

3.3 Level 2
This level is composed of a single layer which consist in a global real-time and graphical demonstration based on
the middleware service layer, the low-level abstraction layer and the basic peripheral usage applications for board
based features.

3.4 Utilities
Alike all STM32Cube firmware packages, the STM32CubeU5 provides a set of utilities that offer miscellaneous
software and additional system resources services that can be used by either the application or the different
STM32Cube Firmware intrinsic middleware and components.

3.4.1 LPBAM Utility

The STM32U5 series embeds the Low Power Background Autonomous Mode subsystem, which is s an
operating mode that allows peripherals to be functional and autonomous independently from power modes and
without any software running. It can chain diverse operations thanks to DMA linked-list transfers.
The LPBAM utility is a set of modular drivers located under Utilities folder in the STM32Cube firmware package. It
provides two user levels of abstraction: Basic and Advanced levels.

Figure 3. LPBAM Utility layers

The LPBAM utility is based on layers:

• The first level of abstraction is a hardware agnostic layer named Basic LPBAM layer. It gives to the users a
full granularity of scenarios creation via transversal APIs.

UM2883 - Rev 1 page 8/31

UM2883
Utilities

• The second level of abstraction is a hardware agnostic layer named Advanced LPBAM layer. It provides a
predefined scenario (set of elementary nodes) that can be customized and concatenated to build an end
user application.
• The Platform layer contains device specific constants to be used by the applicative side.
• The LL LPBAM layer (low level) is used by the Basic and the Advanced LPBAM layers. It contains the
device specific mechanisms for each supported peripheral.

UM2883 - Rev 1 page 9/31

UM2883
STM32CubeU5 MCU package overview

4 STM32CubeU5 MCU package overview

4.1 Supported STM32U5 Series devices and hardware

STM32Cube offers a highly portable hardware abstraction layer (HAL) built around a generic architecture. It
allows the build-upon layers principle, such as using the middleware layer to implement their functions without
knowing, in-depth, what MCU is used. This improves the library code re-usability and guarantees an easy
portability to other devices.
In addition, thanks to its layered architecture, the STM32CubeU5 offers full support of all STM32U5 Series. The
user has only to define the right macro in stm32u5xx.h.
Table 1 shows the macro to define depending on the STM32U5 Series device used. This macro must also be
defined in the compiler preprocessor.

Table 1. Macros for STM32U5 Series

Macro defined in
STM32U5 devices
stm32u5xx.h

STM32U575ZIT6, STM32U575QII6, STM32U575AII6, STM32U575CIU6Q, STM32U575CIT6Q,

STM32U575OIY6Q, STM32U575VIT6Q, STM32U575QII6Q, STM32U575ZIT6Q,
STM32U575RIT6Q, STM32U575CGU6, STM32U575CGT6, STM32U575RGT6,
STM32U575xx
STM32U575VGT6, STM32U575ZGT6, STM32U575QGI6, STM32U575AGI6,
STM32U575CGU6Q, STM32U575CGT6Q, STM32U575OGY6Q, STM32U575VGT6Q,
STM32U575QGI6Q, STM32U575ZGT6Q, STM32U575RGT6Q, STM32U575AGI6Q.
STM32U585CIU6, STM32U585CIT6, STM32U585RIT6, STM32U585VIT6, STM32U585AII6,
STM32U585QII6, STM32U585ZIT6, STM32U585OIY6Q, STM32U585VIT6Q, STM32U585QEI6Q,
STM32U585xx
STM32U585RIT6Q, STM32U585AII6Q, STM32U585CIU6Q, STM32U585CIT6Q,
STM32U585ZET6Q.

STM32CubeU5 features a rich set of examples and applications at all levels making it easy to understand and
use any HAL driver and/or middleware components. These examples run on the STMicroelectronics boards listed
in Table 2.

Table 2. Boards for STM32U5 Series

Board Board STM32U5 supported devices

NUCLEO-U575ZI-Q STM32U575ZIT6Q
STM32U575I-EV STM32U575AII6Q
B-U585I-IOT02A STM32U585AII6Q

The STM32CubeU5 MCU package is able to run on any compatible hardware. The user simply updates the BSP
drivers to port the provided examples on his own board, if the latter has the same hardware features (such as
LED, LCD display, buttons).

4.2 MCU package overview

The STM32CubeU5 MCU package solution is provided in one single zip package having the structure shown in
Figure 4.

UM2883 - Rev 1 page 10/31

UM2883
MCU package overview

Figure 4. STM32CubeU5 MCU package structure

BSP drivers for the supported boards:

- Evaluation board
- Discovery kit
- Nucleo kit

Contains STM32U5xx STM32U5xx HAL & LL drivers

CMSIS files that define
peripheral register
declarations, bit definitions
and address mapping

Azure RTOS middleware

STMTouch library
USB power delivery
libraries

Set of examples, Open Source middleware

applications, and
demonstrations organized
by board and provided with
preconfigured projects (user
modifiable files)

Project examples list per board

Miscellaneous utilities

STM32CubeU5 firmware
package release note and
license

1. The component files must not be modified by the user. Only the \Projects sources are editable by the user.

For each board, a set of examples are provided with pre-configured projects for EWARM, MDK-ARM, and
STM32CubeIDE toolchains.
Figure 5 shows the project structure for the NUCLEO-U575ZI-Q board.

UM2883 - Rev 1 page 11/31

UM2883
MCU package overview

Figure 5. STM32CubeU5 examples overview

UM2883 - Rev 1 page 12/31

UM2883
MCU package overview

The examples are classified depending on the STM32Cube level they apply to, and are named as explained
below:
• Level 0 examples are called "Examples"," Examples_LL" and "Examples_MIX". They use respectively HAL
drivers, LL drivers and a mix of HAL and LL drivers without any middleware component.
• Level 1 examples are called Applications. They provide typical use cases of each middleware component.
Any firmware application for a given board can be quickly build thanks to template projects available in the
Templates and Templates_LL directories.

4.2.1 TrustZone-enabled projects

TrustZone-enabled “Examples” names are prefixed with "_TrustZone". The rule is applied also for “Applications”
(except TFM which is natively for TrustZone®).
TrustZone-enabled “Examples” and “Applications” are provided with a multi-project structure composed of secure
and non-secure sub-projects as presented below in Figure 6.
TrustZone-enabled projects are developed according to CMSIS-5 device template extended to include the
system partitioning header file partition_<device>.h responsible for principally the setup of the secure attribute unit
(SAU), the FPU and the secure/non-secure interrupts assignment in secure execution state.
This setup is performed in secure CMSIS SystemInit() function called at startup before entering the secure
application main() function (refer to Arm TrustZone-M documentation of software guidelines).

UM2883 - Rev 1 page 13/31

UM2883
MCU package overview

Figure 6. Secure and non-secure multi-projects structure

Non-secure project configuration

Secure project configuration

Non-secure project linker file

Secure project linker file

Non-secure project application include

and source files

CMSIS device partition file for IDAU/

SAU, FPU, core and secure/non-
secure interrupts configuration

Secure project application include and

source files

Non-secure callable services

Non-secure callable header file

(shared by secure project to non-
secure project)

Non-secure project components

Secure project components

The STM32CubeU5 firmware package provides default memory partitioning in the partition_<device>.h files
available under:
\Drivers\CMSIS\Device\ST\STM32U5xx\Include\Templates.

UM2883 - Rev 1 page 14/31

UM2883
MCU package overview

In these partition files, the SAU is disabled by default. Consequently, the IDAU memory mapping is used for
security attribution (refer to Figure 3 in Reference Manual)
If SAU is enabled by the user, a default SAU region configuration is pre-defined in partition files as follows:
• SAU region 0: 0x0C0FE000 - 0x0C0FFFFF (secure, non-secure callable)
• SAU region 1: 0x08100000 - 0x081FFFFF (non-secure Flash memory Bank2 (1024 Kbytes))
• SAU region 2: 0x20040000 - 0x200BFFFF (non-secure SRAM3 (512 Kbytes)))
• SAU region 3: 0x40000000-0x4FFFFFFF (non-secure peripheral mapped memory)
• SAU region 4: 0x60000000-0x9FFFFFFF (non-secure external memories)
• SAU region 5: 0x0BF90000-0x0BFA8FFF (non-secure system memory)
To match the default partitioning, the STM32U5xx Series devices must have the following user option bytes set:
• TZEN=1 (TrustZone-enabled device)
• SECWM1_PSTRT=0x0 SECWM1_PEND=0x7F (all 128 pages of Flash memory Bank1 set as secure)
• SECWM2_PSTRT=0x1 SECWM2_PEND=0x0 (no page of Flash memory Bank2 set as secure, hence Bank2 is
non-secure).
Note: The internal Flash memory is fully secure by default in TZEN=1 and user option bytes SECWM1_PSTRT/
SECWM1_PEND and SECWM2_PSTRT/SECWM2_PEND must be set according to the application memory
configuration (SAU regions (if SAU is enabled) and secure/non-secure applications project linker files must be
aligned too).
All examples have the same structure:
• \Inc folder that contains all header files.
• \Src folder for the sources code.
• \EWARM, \MDK-ARM, and \STM32CubeIDE folders containing the pre-configured project for each toolchain.
• readme.txt describing the example behavior and needed environment to make it work
• *.ioc file that allows users to open most of firmware examples within STM32CubeMX
Table 3 gives the number of projects available for each board.

Table 3. Number of examples for each board

Level B-U585I-IOT02A STM32U575I-EV NUCLEO-U575ZI-Q Total

Templates_LL 1 1 1 3
Templates 2 2 2 6
Examples_MIX 0 0 5 5
Examples_LL 0 0 41 41
Examples 23 27 85 135
Demonstrations 1 1 0 2
Applications 16 2 38 56
Total 43 35 172 250

UM2883 - Rev 1 page 15/31

UM2883
Getting started with STM32CubeU5

5 Getting started with STM32CubeU5

5.1 Running a first example

This section explains how simple it is to run a first example on an STM32U5 Series board. The program simply
toggles a LED on the NUCLEO-U575ZI-Q board:
Download the STM32CubeU5 MCU package. Unzip it into an appropriate directory. Make sure the package
structure shown in Figure 4 is not modified. Note that it is also recommended to copy the package as close as
possible to the root volume (for example C\ST or G:\Tests) because some IDEs encounter problems when the
path length is too long.

5.1.1 Running a first TrustZone-enabled example

Prior to loading and running a TrustZone-enabled example, it is mandatory to read the example readme file for
any specific configuration which insures that the security is enabled as described in Section 4.2.1 (TZEN=1 (user
option byte)).
1. Browse to \Projects\NUCLEO-U575ZI-Q\Examples.
2. Open \GPIO, then \GPIO_IoToggle_TrustZone folders.
3. Open the project with the preferred toolchain. A quick overview on how to open, build and run an example
with the supported toolchains is given below.
4. Rebuild in sequence all secure and non-secure project files and load the secure and non-secure images into
target memory.
5. Run the example: on a regular basis, the secure application toggles LED1 every second and non-secure
application toggles LED2 twice as fast (for more details, refer to the example readme file).
To open, build and run an example with the supported toolchains, follow the steps below:
• EWARM
1. Under the example folder, open \EWARM sub-folder
2. Launch the Project.eww workspace
3. Set the "xxxxx_S" as active application (right click on xxxxx_S project Set as Active)
4. Rebuild the xxxxx_S secure project files: Project → Rebuild all
5. Rebuild the xxxxx_NS non-secure project files: Right click on xxxxx_NS project → Rebuild all
6. Flash the secure and non-secure binaries with Download and Debug button (Ctrl+D)
7. Run program: Debug → Go(F5)

UM2883 - Rev 1 page 16/31

UM2883
Running a first example

• MDK-ARM
1. Open the MDK-ARM toolchain
2. Open Multi-projects workspace file Project.uvmpw
3. Select the xxxxx_s project as Active Project (Set as Active Project)
4. Build xxxxx_s project
5. Select the xxxxx_ns project as Active Project (Set as Active Project)
6. Build xxxxx_ns project
7. Load the non-secure binary (F8)
(this downloads the \MDK-ARM\xxxxx_ns\Exe\xxxxx_ns.axf to flash memory)
8. Select the Project_s project as Active Project (Set as Active Project)
9. Load the secure binary (F8)
(this downloads the \MDK-ARM\xxxxx_s\Exe\xxxxx_s.axf to flash memory)
10. Run the example
STM32CubeIDE
1. Open the STM32CubeIDE toolchain
2. Open Multi-projects workspace file .project
3. Rebuild xxxxx_Secure project
4. Rebuild xxxxx_NonSecure project
5. Launch Debug as STM32 Cortex-M C/C++ Application for the secure project.
6. In the Edit configuration window, select the Startup panel, and add load image and symbols of the
non-secure project.
7. Be careful, the non-secure project has to be loaded before the secure project.
8. Then click "OK".
9. Run the example on debug perspective.

5.1.2 Running a first TrustZone-disabled example

Prior to loading and running a TrustZone-disabled example, it is mandatory to read the example readme file
for any specific configuration or if nothing is mentioned, ensure that the board device has the security disabled
(TZEN=0 (user option byte)). See FAQ for doing the optional regression to TZEN=0.
1. Browse to \Projects\NUCLEO-U575ZI-Q\Examples.
2. Open \GPIO, then \GPIO_EXTI folders.
3. Open the project with a preferred toolchain. A quick overview on how to open, build and run an example with
the supported toolchains is given below.
4. Rebuild all files and load the image into target memory.
5. Run the example: each time the USER pushbutton is pressed, LED1 toggles (for more details, refer to the
example readme file).
To open, build and run an example with the supported toolchains, follow the steps below:
• EWARM
1. Under the example folder, open \EWARM sub-folder
2. Launch the Project.eww workspace
Note: The workspace name may change from one example to another.
3. Rebuild all files: Project → Rebuild all
4. Load project image: Project → Debug
5. Run program: Debug → Go(F5)

UM2883 - Rev 1 page 17/31

UM2883
Developing a custom application

• MDK-ARM
1. Under the example folder, open \MDK-ARM sub-folder
2. Launch the Project.uvprojx workspace
Note: The workspace name may change from one example to another.
3. Rebuild all files: Project → Rebuild all target files
4. Load project image: Debug → Start/Stop Debug Session
5. Run program: Debug → Run (F5).
• STM32CubeIDE
1. Open the STM32CubeIDE toolchain
2. Click File → Switch Workspace → Other and browse to the STM32CubeIDE workspace directory
3. Click File → Import, select General → Existing Projects into Workspace and then click Next
4. Browse to the STM32CubeIDE workspace directory and select the project
5. Rebuild all project files: select the project in the Project explorer window then click the Project →
build project menu
6. Run program: Run → Debug (F11)

5.2 Developing a custom application

Note: The instruction cache (ICACHE) must be enabled by software to get a 0 wait-state execution from Flash memory
and external memories, and reach the maximum performance and a better power consumption.
Note: The data cache (DCACHE) introduced on S-AHB system bus of Cortex®-M33 processor to improve the
performance of data traffic to/from external memories, must be enabled when using external memories.

5.2.1 Using STM32CubeMX to develop or update an application

In the STM32CubeU5 MCU package, nearly all example projects are generated with the STM32CubeMX tool to
initialize the system, peripherals and middleware.
The direct use of an existing example project from the STM32CubeMX tool requires STM32CubeMX 6.3.0 or
higher:
• After the installation of STM32CubeMX, open and if necessary update a proposed project. The simplest way
to open an existing project is to double-click on the *.ioc file so that STM32CubeMX automatically opens the
project and its source files.
• The initialization source code of such projects is generated by STM32CubeMX; the main application source
code is contained by the comments “USER CODE BEGIN” and “USER CODE END”. In case the IP
selection and setting are modified, STM32CubeMX updates the initialization part of the code but preserves
the main application source code.
For developing a custom project in the STM32CubeMX, follow the step-by-step process:
1. Select the STM32 microcontroller that matches the required set of peripherals.
2. Configure all the required embedded software using a pinout-conflict solver, a clock-tree setting helper, a
power consumption calculator, and the utility performing MCU peripheral configuration (such as GPIO or
USART) and middleware stacks (such as USB).
3. Generate the initialization C code based on the selected configuration. This code is ready to use within
several development environments. The user code is kept at the next code generation.
For more information about STM32CubeMX, refer to the STM32CubeMX for STM32 configuration and
initialization C code generation (UM1718).
For a list of the available example projects for the STM32CubeU5, refer to the STM32Cube firmware examples for
STM32U5 Series application note.

5.2.2 HAL application

This section describes the steps required to create a custom HAL application using STM32CubeU5:

UM2883 - Rev 1 page 18/31

UM2883
Developing a custom application

1. Create a project
To create a new project, start either from the Template project provided for each
board under \Projects\<STM32xxx_yyy>\Templates or from any available project under
\Projects\<STM32xxy_yyy>\Examples or \Projects\<STM32xx_yyy>\Applications (where <STM32xxx_yyy>
refers to the board name, such as STM32CubeU5).
The Template project provides an empty main loop function, however it is a good starting point to understand
the STM32CubeU5 project settings. The template has the following characteristics:
– It contains the HAL source code, CMSIS and BSP drivers which are the minimum set of components
required to develop a code on a given board.
– It contains the include paths for all the firmware components.
– It defines the supported STM32U5 Series devices, allowing the CMSIS and HAL drivers to be
configured correctly.
– It provides read-to-use user files pre-configured as shown below:
HAL initialized with default time base with Arm core SysTick.
SysTick ISR implemented for HAL_Delay() purpose.
Note: When copying an existing project to another location, make sure all the include paths are updated.
2. Add the necessary middleware to user project (optional)
To identify the source files to be added to the project file list, refer to the documentation provided for each
middleware. Refer to the applications under \Projects\STM32xxx_yyy\Applications\<MW_Stack> (where
<MW_Stack> refers to the middleware stack, such as USBX) to know which source files and which include
paths must be added.
3. Configure the firmware components
The HAL and middleware components offer a set of build time configuration options using macros #define
declared in a header file. A template configuration file is provided within each component which has to
be copied to the project folder (usually the configuration file is named xxx_conf_template.h, the word
‘_template’ needs to be removed when copying it to the project folder). The configuration file provides
enough information to understand the impact of each configuration option. More detailed information is
available in the documentation provided for each component.
4. Start the HAL Library
After jumping to the main program, the application code must call HAL_Init() API to initialize the HAL
Library, which carries out the following tasks:
a. Configuration of the Flash memory prefetch and SysTick interrupt priority (through macros defined in
stm32u5xx_hal_conf.h).
b. Configuration of the SysTick to generate an interrupt every millisecond at the SysTick interrupt priority
TICK_INT_PRIO defined in stm32u5xx_hal_conf.h, which is clocked by the MSI (at this stage, the
clock is not yet configured and thus the system is running from the 4 MHz MSI).
c. Setting of NVIC group priority to 0.
d. Call of HAL_MspInit() callback function defined in stm32u5xx_hal_msp.c user file to perform global
low-level hardware initializations.

UM2883 - Rev 1 page 19/31

UM2883
Developing a custom application

5. Configure the system clock

The system clock configuration is done by calling the two APIs described below:
– HAL_RCC_OscConfig(): this API configures the internal and/or external oscillators, as well as the
PLL source and factors. The user chooses to configure one oscillator or all oscillators. The PLL
configuration can be skipped if there is no need to run the system at high frequency.
– HAL_RCC_ClockConfig(): this API configures the system clock source, the Flash memory latency
and AHB and APB prescalers.
Initialize the peripheral
a. First write the peripheral HAL_PPP_MspInit function. Proceed as follows:
◦ Enable the peripheral clock.
◦ Configure the peripheral GPIOs.
◦ Configure the DMA channel and enable DMA interrupt (if needed).
◦ Enable peripheral interrupt (if needed).
b. Edit the stm32xxx_it.c to call the required interrupt handlers (peripheral and DMA), if needed.
c. Write process complete callback functions if peripheral interrupt or DMA is planned to be used.
d. In user main.c file, initialize the peripheral handle structure then call the function HAL_PPP_Init() to
initialize the peripheral.
6. Develop an application
At this stage, the system is ready and user application code development can start.
a. The HAL provides intuitive and ready-to-use APIs to configure the peripheral. It supports polling,
interrupts and a DMA programming model, to accommodate any application requirements. For more
details on how to use each peripheral, refer to the rich example set provided in the STM32CubeU5
MCU package.
Caution: In the default HAL implementation, SysTick timer is used as timebase: it generates interrupts at regular time
intervals. If HAL_Delay() is called from peripheral ISR process, make sure that the SysTick interrupt has
higher priority (numerically lower) than the peripheral interrupt. Otherwise, the caller ISR process is blocked.
Functions affecting timebase configurations are declared as __weak to make override possible in case of other
implementations in user file (using a general purpose timer for example or other time source). For more details,
refer to HAL_TimeBase example.

UM2883 - Rev 1 page 20/31

UM2883
Getting STM32CubeU5 release updates

5.2.3 LL application
This section describes the steps needed to create a custom LL application using STM32CubeU5.
1. Create a project
To create a new project, either start from the Templates_LL project provided for each
board under \Projects\<STM32xxx_yyy>\Templates_LL or from any available project under
\Projects\<STM32xxy_yyy>\Examples_LL (<STM32xxx_yyy> refers to the board name, such as NUCLEO-
U575ZI-Q).
The template project provides an empty main loop function, which is a good starting point to understand the
project settings for STM32CubeU5. Template main characteristics are the following:
– It contains the source codes of the LL and CMSIS drivers which are the minimum set of components
needed to develop code on a given board.
– It contains the include paths for all the required firmware components.
– It selects the supported STM32U5 device and allows the correct configuration of the CMSIS and LL
drivers.
– It provides ready-to-use user files, that are pre-configured as follows:
◦ main.h: LED & USER_BUTTON definition abstraction layer.
◦ main.c: system clock configuration for maximum frequency.
2. Port an existing project to another board
To port an existing project to another target board, start from the Templates_LL project provided for each
board and available under \Projects\<STM32xxx_yyy>\Templates_LL:
a. Select a LL example
To find the board on which LL examples are deployed, refer to the list of LL examples
STM32CubeProjectsList.html.
3. Port the LL example
– Copy/paste the Templates_LL folder - to keep the initial source - or directly update existing
Templates_LL project.
– Then porting consists principally in replacing Templates_LL files by the Examples_LL targeted project.
– Keep all board specific parts. For reasons of clarity, board specific parts have been flagged with
specific tags:

/* ============== BOARD SPECIFIC CONFIGURATION CODE BEGIN ============== */

/* ============== BOARD SPECIFIC CONFIGURATION CODE END ============== */

Thus the main porting steps are the following:

◦ Replace the stm32u5xx_it.h file
◦ Replace the stm32u5xx_it.c file
◦ Replace the main.h file and update it: keep the LED and user button definition of the LL template
under ‘BOARD SPECIFIC CONFIGURATION’ tags.
◦ Replace the main.c file and update it:
Keep the clock configuration of the SystemClock_Config() LL template function under
‘BOARD SPECIFIC CONFIGURATION’ tags.
Depending on LED definition, replace each LEDx occurrence with another LEDy available in
main.h.
With these modifications, the example now runs on the targeted board.

5.3 Getting STM32CubeU5 release updates

The new STM32CubeU5 MCU package releases and patches are available from www.st.com/stm32u5. They may
be retrieved from the "CHECK FOR UPDATE" button in STM32CubeMX. For more details, refer to section 3 of
STM32CubeMX for STM32 configuration and initialization C code generation (UM1718).

UM2883 - Rev 1 page 21/31

UM2883
FAQ

6 FAQ

6.1 What is the license scheme for the STM32CubeU5 MCU package?
The HAL is distributed under a non-restrictive BSD (berkeley software distribution) license.
The middleware stacks made by STMicroelectronics (ex: USBPD library) come with a licensing model allowing
easy reuse, provided it runs on an STMicroelectronics device.
The middleware based on well-known open-source solutions (TFM) have user-friendly license terms. For more
details, refer to the appropriate middleware license agreement.

6.2 What boards are supported by the STM32CubeU5 MCU package?

The STM32CubeU5 MCU package provides BSP drivers and ready-to-use examples for the following STM32U5
Series boards:
• NUCLEO-U575ZI-Q
• STM32U575I-EV
• B-U585I-IOT02A

6.3 Are any examples provided with the ready-to-use toolset projects?
Yes. STM32CubeU5 provides a rich set of examples and applications. They come with the pre-configured projects
for IAR Embedded Workbench®, Keil® and STM32CubeIDE.

6.4 How to enable TrustZone® on STM32U5 Series devices?

All STM32U5 Series devices support TrustZone®. Factory default state is TrustZone® disabled. The TrustZone®
security is activated with the TZEN option bit in the FLASH_OPTR register. The user option bytes configuration
may be done with STM32CubeProgrammer (STM32CubeProg).

6.5 How to disable TrustZone® on STM32U5 Series devices?

The following sequence is needed to disable TrustZone®:
• Boot from user Flash memory:
1. Make sure that secure and non-secure applications are well loaded and executed (jump done on
non-secure application).
2. If not yet done, set RDP to level 1 through STM32CubeProgrammer. Then only Hotplug connection is
possible during non-secure application execution.
3. Use a power supply different than ST-LINK in order to be able to connect to the target.
4. Uncheck the "TZEN" box and set RDP to level 0 (option byte value 0xAA), then click on "Apply".
• Boot from RSS:
1. Make sure to apply a high level on BOOT0 pin (make sure that "nSWBOOT0 Option Byte" is checked).
2. If not yet done, set RDP to level 1 through STM32CubeProgrammer. Then only Hotplug connection is
possible during non-secure application execution.
3. Use a power supply different than ST-LINK in order to be able to connect to the target.
4. Uncheck the "TZEN" box and set RDP to level 0 (option byte value 0xAA), then click on "Apply".
Refer to AN5347 for more details.

UM2883 - Rev 1 page 22/31

UM2883
How to update the secure / non-secure memory mapping

6.6 How to update the secure / non-secure memory mapping

In case of memory isolation for secure and non-secure applications, the secure and non-secure 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 non-secure applications requires the following updates
and alignments (without overlap between secure and non-secure memory space and using secure and non-
secure memory address aliases):
• If SAU is enabled, non-secure area update (internal Flash and SRAMs) (see partition_stm32u5xx.h file).
• Secure and non-secure linker files update to correctly locate the secure and non-secure code and data.
• Update the non-secure address to jump to (in secure main.c and non-secure reset handler in non-secure
linker file)
• Update the Flash 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 non-secure 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
non-secure 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 non-secure application to secure address.
If 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 hardware. a set of user-friendly APIs allow a
higher abstraction level which 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 allows an easier migration from the SPL to the STM32CubeU5 LL drivers, since each SPL
API has its equivalent LL API(s).

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).

UM2883 - Rev 1 page 23/31

UM2883
How are the product/peripheral specific features managed?

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.

6.12 When should the HAL be used versus LL drivers?

HAL drivers offer high-level and function-oriented APIs, with a high level of portability. Product/IPs complexity is
hidden for end users.
LL drivers offer low-layer register level APIs, with a better optimization but less portable. They require in depth
knowledge of product/IPs specifications.

6.13 How can LL drivers be included in an existing environment? Is there any LL

configuration file as for HAL?
There is no configuration file. Source code shall directly include the necessary stm32u5xx_ll_ppp.h file(s).

6.14 Can HAL and LL drivers be used together? If yes, what are the constraints?
It is possible to use both HAL and LL drivers. Use the HAL for the IP initialization phase and then manage the I/O
operations with LL drivers.
The major difference between HAL and LL is that HAL drivers require to create and use handles for operation
management while LL drivers operates directly on peripheral registers. Mixing HAL and LL is illustrated in the
"Examples_MIX" example.

6.15 Are there any LL APIs which are not available with HAL?
Yes, there are. A few Cortex® APIs have been added in stm32u5xx_ll_cortex.h, for instance for accessing SCB or
SysTick registers.

6.16 Why are SysTick interrupts not enabled on LL drivers?

When using LL drivers in standalone mode, there is no need to enable SysTick interrupts because they are not
used in LL APIs, while HAL functions require SysTick interrupts to manage timeouts.

6.17 How are LL initialization APIs enabled?

The definition of LL initialization APIs and associated resources (structures, literals and prototypes) is conditioned
by the USE_FULL_LL_DRIVER compilation switch.
To be able to use LL initialization APIs, add this switch in the toolchain compiler preprocessor.

6.18 How can STM32CubeMX generate code based on embedded software?

STM32CubeMX has a built-in knowledge of STM32 microcontrollers, including their peripherals and software, that
allows to provide a graphical representation to the user and generate *.h/*.c files based on user configuration.

6.19 How to get regular updates on the latest STM32CubeU5 MCU package
releases?
Refer to Section 5.3 .

6.20 What is an LPBAM mechanism?

The LPBAM mechanism is a subsystem that operates independently from low power mode and without any
software running (CPU intervention).

UM2883 - Rev 1 page 24/31

UM2883
Is the LPBAM based on DMA "tasks" used to configure the peripherals?

The low power mode depends on products integration.

6.21 Is the LPBAM based on DMA "tasks" used to configure the peripherals?
The LPBAM is based on DMA transfers stored on linked-list nodes to configure partially autonomous peripherals.

6.22 How are managed the priorities between LPBAM and others DMA transfer?
The LPBAM is based on DMA transfer, the same DMA channels priority arbitration principle applies.

UM2883 - Rev 1 page 25/31

UM2883

Revision history

Table 4. Document revision history

Date Revision Changes

24-Jun-2021 1 Initial release.

UM2883 - Rev 1 page 26/31

UM2883
Contents

Contents
1 General information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 STM32CubeU5 main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 STM32CubeU5 architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Level 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1 Board support package (BSP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1.2 Hardware abstraction layer (HAL) and low-layer (LL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1.3 Basic peripheral usage examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2 Level 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1 Middleware components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2.2 Examples based on the middleware components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.3 Level 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4 Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4.1 LPBAM Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4 STM32CubeU5 MCU package overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

4.1 Supported STM32U5 Series devices and hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 MCU package overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1 TrustZone-enabled projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5 Getting started with STM32CubeU5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

5.1 Running a first example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.1 Running a first TrustZone-enabled example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.1.2 Running a first TrustZone-disabled example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.2 Developing a custom application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.2.1 Using STM32CubeMX to develop or update an application. . . . . . . . . . . . . . . . . . . . . . . . 18

5.2.2 HAL application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.2.3 LL application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.3 Getting STM32CubeU5 release updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6 FAQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
6.1 What is the license scheme for the STM32CubeU5 MCU package? . . . . . . . . . . . . . . . . . . . 22
6.2 What boards are supported by the STM32CubeU5 MCU package? . . . . . . . . . . . . . . . . . . . 22
6.3 Are any examples provided with the ready-to-use toolset projects?. . . . . . . . . . . . . . . . . . . . 22

UM2883 - Rev 1 page 27/31

UM2883
Contents

6.4 How to enable TrustZone® on STM32U5 Series devices? . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6.5 How to disable TrustZone® on STM32U5 Series devices? . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6.6 How to update the secure / non-secure memory mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.7 How to set up interrupts for secure and non-secure applications . . . . . . . . . . . . . . . . . 23
6.8 Why does the system enter in SecureFault_Handler()? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.9 Are there any links with standard peripheral libraries? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.10 Does the HAL layer take advantage of interrupts or DMA? How can this be
controlled? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.11 How are the product/peripheral specific features managed?. . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.12 When should the HAL be used versus LL drivers?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.13 How can LL drivers be included in an existing environment? Is there any LL configuration
file as for HAL? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.14 Can HAL and LL drivers be used together? If yes, what are the constraints? . . . . . . . 24
6.15 Are there any LL APIs which are not available with HAL? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.16 Why are SysTick interrupts not enabled on LL drivers? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.17 How are LL initialization APIs enabled? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.18 How can STM32CubeMX generate code based on embedded software? . . . . . . . . . . . . . . 24
6.19 How to get regular updates on the latest STM32CubeU5 MCU package releases? . . . . . . 24
6.20 What is an LPBAM mechanism?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.21 Is the LPBAM based on DMA "tasks" used to configure the peripherals? . . . . . . . . . . . . . . . 25
6.22 How are managed the priorities between LPBAM and others DMA transfer? . . . . . . . . . . . . 25

Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
List of tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
List of figures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30

UM2883 - Rev 1 page 28/31

UM2883
List of tables

List of tables
Table 1. Macros for STM32U5 Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Table 2. Boards for STM32U5 Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Table 3. Number of examples for each board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Table 4. Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

UM2883 - Rev 1 page 29/31

UM2883
List of figures

List of figures
Figure 1. STM32CubeU5 MCU package components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Figure 2. STM32CubeU5 MCU package architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Figure 3. LPBAM Utility layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Figure 4. STM32CubeU5 MCU package structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figure 5. STM32CubeU5 examples overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Figure 6. Secure and non-secure multi-projects structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

UM2883 - Rev 1 page 30/31

UM2883

IMPORTANT NOTICE – PLEASE READ CAREFULLY

STMicroelectronics NV and its subsidiaries (“ST”) reserve the right to make changes, corrections, enhancements, modifications, and improvements to ST
products and/or to this document at any time without notice. Purchasers should obtain the latest relevant information on ST products before placing orders. ST
products are sold pursuant to ST’s terms and conditions of sale in place at the time of order acknowledgement.
Purchasers are solely responsible for the choice, selection, and use of ST products and ST assumes no liability for application assistance or the design of
Purchasers’ products.
No license, express or implied, to any intellectual property right is granted by ST herein.
Resale of ST products with provisions different from the information set forth herein shall void any warranty granted by ST for such product.
ST and the ST logo are trademarks of ST. For additional information about ST trademarks, please refer to www.st.com/trademarks. All other product or service
names are the property of their respective owners.
Information in this document supersedes and replaces information previously supplied in any prior versions of this document.
© 2020 STMicroelectronics – All rights reserved

UM2883 - Rev 1 page 31/31