UM2550

User manual
Getting started with STM32CubeWB for STM32WB Series

Introduction
STM32Cube is an STMicroelectronics original initiative to make developers’ lives easier by
reducing development effort, time and cost. STM32Cube covers the whole STM32 portfolio.
STM32Cube includes:
• STM32CubeMX, a graphical software configuration tool that allows the generation of C
initialization code using graphical wizards.
• A comprehensive embedded software platform, delivered per Series (such as
STM32CubeWB for STM32WB Series):
– The STM32Cube HAL, STM32 abstraction layer embedded software ensuring
maximized portability across STM32 portfolio. The HAL is available for all
peripherals
– Low-layer APIs (LL) offering a fast light-weight expert-oriented layer which is
closer to the hardware than the HAL. LL APIs are available only for a set of
peripherals.
– A consistent set of middleware components such as USB Device, STMTouch
(STM32 touch sensing library), STM32_WPAN (Bluetooth® Low Energy 5.0,
OpenThread, 802-15-4 MAC, ZigBee), FatFS and FreeRTOS.
– All embedded software utilities coming with a full set of examples.
This user manual describes how to get started with the STM32CubeWB MCU Package.
Section 1 describes the main features of the STM32CubeWB MCU Package.
Section 2 and Section 3 provide an overview of the STM32CubeWB architecture and MCU
Package structure.

February 2020 UM2550 Rev 3 1/30

www.st.com 1
Contents UM2550

Contents

1 STM32CubeWB main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 STM32CubeWB architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1 Level 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1 Board support package (BSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.2 Hardware abstraction layer (HAL) and low-layer (LL) . . . . . . . . . . . . . . . 9
2.1.3 Basic peripheral usage examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Level 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 Middleware components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2 ZigBee stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.3 Examples based on the middleware components . . . . . . . . . . . . . . . . . 12
2.3 Level 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 STM32CubeWB firmware package overview . . . . . . . . . . . . . . . . . . . . 13

3.1 Supported STM32WB devices and hardware . . . . . . . . . . . . . . . . . . . . . 13
3.2 Firmware package overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Getting started with STM32CubeWB . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1 Running your first example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Developing your own application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.1 Using STM32CubeMX to develop or update your application . . . . . . . . 18
4.2.2 HAL application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.3 LL application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.4 Installing and running the STM32CubeUpdater program . . . . . . . . . . . 22

5 How to flash the wireless coprocessor binary . . . . . . . . . . . . . . . . . . . 23

6 FAQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1 What is the license scheme for the STM32CubeWB firmware? . . . . . . . . 26
6.2 What boards are supported by the STM32CubeWB firmware package? . 26
6.3 Are any examples provided with the ready-to-use toolset projects? . . . . 26
6.4 Is there any link with Standard Peripheral Libraries? . . . . . . . . . . . . . . . . 26
6.5 Does the HAL layer take benefit from interrupts or DMA?
How can this be controlled? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2/30 UM2550 Rev 3

UM2550 Contents

6.6 How are the product/peripheral specific features managed? . . . . . . . . . . 27

6.7 How can STM32CubeMX generate code based on embedded software? 27
6.8 When should I use HAL versus LL drivers? . . . . . . . . . . . . . . . . . . . . . . . 27
6.9 How can I include LL drivers in my environment?
Is there any LL configuration file as for HAL? . . . . . . . . . . . . . . . . . . . . . 27
6.10 Can I use HAL and LL drivers together? If yes, what are the constraints? 27
6.11 Are there any LL APIs which are not available with HAL? . . . . . . . . . . . . 28
6.12 Why are SysTick interrupts not enabled on LL drivers? . . . . . . . . . . . . . . 28
6.13 How are LL initialization APIs enabled? . . . . . . . . . . . . . . . . . . . . . . . . . . 28

7 Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

UM2550 Rev 3 3/30

3
List of tables UM2550

List of tables

Table 1. Macros for STM32WB Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Table 2. Boards for STM32WB Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Table 3. Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4/30 UM2550 Rev 3

UM2550 List of figures

List of figures

Figure 1. STM32CubeWB firmware components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Figure 2. STM32CubeWB firmware architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Figure 3. STM32CubeWB firmware package structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figure 4. Overview of STM32CubeWB examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

UM2550 Rev 3 5/30

5
STM32CubeWB main features UM2550

1 STM32CubeWB main features

The STM32CubeWB MCU Package runs on STM32 32-bit microcontrollers based on the
Arm®(a) Cortex®-M processor.
STM32CubeWB gathers, in a single package, all the generic embedded software
components required to develop an application on STM32WB microcontrollers. In line with
the STM32Cube initiative, this set of components is highly portable, not only within
STM32WB Series but also to other STM32 Series.
STM32CubeWB is fully compatible with STM32CubeMX code generator that allows
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.
STM32CubeWB MCU Package also contains a set of middleware components with the
corresponding examples. They come in free user-friendly license terms:
• CMSIS-RTOS implementation with FreeRTOS™ open source solution
• Full USB Device stack supporting many classes: Audio, HID, MSC, CDC and DFU
• STMTouch, touch sensing library solution
• STM32_WPAN, wireless personal area network middleware developed within the
STM32WB framework to support Bluetooth® Low Energy (BLE) 5.0, 802.15.4
OpenThread certified stacks, 802-15-4 MAC layer and ZigBee.
• FAT file system based on open source FatFS solution
Several applications and demonstrations implementing all these middleware components
are also provided in the STM32CubeWB MCU Package.

a. Arm is a registered trademark of Arm Limited (or its subsidiaries) in the US and or elsewhere.

6/30 UM2550 Rev 3

UM2550 STM32CubeWB main features

Figure 1. STM32CubeWB firmware components

Evaluation Discovery STM32 Nucleo Dedicated

boards boards boards boards User
application Utilities
Application level demonstrations

STM32_WPAN
Touch (Bluetooth,
USB RTOS CMSIS
library Thread and 802-
15-4 MAC layer)

Middleware level (1) Utilities

Board support package (BSP) Low-layer APIs (LL) Hardware abstraction layer APIs (HAL)

HAL and LL APIs

(1) The set of middleware components depends on the product Series. MSv46868V1

UM2550 Rev 3 7/30

29
STM32CubeWB architecture overview UM2550

2 STM32CubeWB architecture overview

The STM32CubeWB firmware solution is built around three independent levels that easily
interact as described in Figure 2.

Figure 2. STM32CubeWB firmware architecture

Level 2 Evaluation board, Nucleo and Discovery Kit demonstrations

Applications

Level 1
Library and protocol based components
(for example FatFS, USB, STMTouch, FreeRTOS™ or
STM32_WPAN)

Examples

Level 0 BSP drivers

Hardware abstraction layer (HAL)

Core drivers (optional) Low-layer (LL)

HAL

MSv61375V1

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

8/30 UM2550 Rev 3

UM2550 STM32CubeWB architecture overview

2.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 provide specific APIs to the BSP driver external components and
could be portable on any other board.
• BSP driver
It allows linking the component driver 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.

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

The STM32CubeWB 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 process. 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 provides 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.

UM2550 Rev 3 9/30

29
STM32CubeWB architecture overview UM2550

2.1.3 Basic peripheral usage examples

This layer encloses the examples build over the STM32 peripheral using only the HAL and
BSP resources.

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

2.2.1 Middleware components

The middleware is a set of libraries covering FatFS. FreeRTOS™, USB Device, STMTouch
(STM32 touch sensing library), and STM32_WPAN middleware. Horizontal interactions
between the components of this layer is done directly 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. For example, the FatFS
implements the disk I/O driver to access microSD™ drive.
The main features of each middleware component are as follows:
• FAT file system
– FatFS FAT open source library
– Long file name support
– Dynamic multi-drive support
– RTOS and standalone operation
– Examples with microSD™
• FreeRTOS™
– Open source standard
– CMSIS compatibility layer
– Tickless operation during low-power mode

10/30 UM2550 Rev 3

UM2550 STM32CubeWB architecture overview

– Integration with all STM32Cube middleware modules

• USB Device library
– Support for several USB classes (Mass-Storage, HID, CDC, DFU, AUDIO and
MTP)
– Support for multipacket transfer: large amount of data can be sent without splitting
the transfer into transactions of maximum size packets.
– Use of configuration files to change the core and the library configuration without
changing the read-only library code.
– 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.
• STM32 touch sensing library
Robust STMTouch capacitive touch sensing solution supporting proximity, touchkey,
linear and rotary touch sensor. It is based on a proven surface charge transfer
acquisition principle.
• STM32 wireless personal area network middleware (STM32_WPAN) developed within
the STM32WB framework
– BLE 5.0 certified stacks
– BLE stack: link layer, HCI, L2CAP, ATT, SM, GAP and GATT database
(Declaration ID D042164, available from see https://launchstudio.bluetooth.com)
– BLE multiprofile subsystem: a complete coverage of BLE software stack profiles
and services (Declaration ID D042214, available from
https://launchstudio.bluetooth.com)
– 802.15.4 Thread® v1.1 stack
The Thread® stack is provided by OpenThread, an open-source implementation of
the Thread® networking protocol (refer to https://openthread.io for more
information on this stack). The stack supports two configurations:
FTD (Full Thread Device), to be used for Leader, Router and End Device Thread
roles (except for Border Router).
MTD (Minimal Thread Device), to be used for End Device and Sleepy End Device
Thread roles.
– 802.15.4 MAC layer
This MAC API is based on the latest official IEEE Std 802.15.4-2011 document
available from http://grouper.ieee.org
It supports Full Function Devices (FFD) and can ensure the role of Personal Area
Network (PAN) coordinator and Reduced Function Device (RFD) that serve as
node for extremely simple applications.

2.2.2 ZigBee stack

ZigBee compliant platform stack (Zigbee PRO feature Set 2017).
• Support of RFD (reduced feature) and FFD configurations (full feature).
• Support of more than 40 clusters (including basic device cluster, temperature
configuration cluster, identify cluster, on/off cluster, power profile cluster, temperature
measurement cluster, pressure measurement cluster, meter identification cluster,
etc…). Refer to the release note for the full list.

UM2550 Rev 3 11/30

29
STM32CubeWB architecture overview UM2550

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

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

12/30 UM2550 Rev 3

UM2550 STM32CubeWB firmware package overview

3 STM32CubeWB firmware package overview

3.1 Supported STM32WB devices and hardware

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

Table 1. Macros for STM32WB Series

Macro defined in stm32wbxx.h STM32WB devices

STM32WB30xx STM32WB30CEU5
STM32WB35CEU6, STM32WB35CEY6, STM32WB35CCU6,
STM32WB35xx
STM32WB35CCY6
STM32WB50xx STM32WB50CGU5
STM32WB55CGU6, STM32WB55CEU6, STM32WB55CCU6,
STM32WB55RGV6, STM32WB55REV6, STM32WB55RCV6,
STM32WB55xx
STM32WB55VGY6, STM32WB55VEY6, STM32WB55VCY6,
STM32WB55VGQ6, STM32WB55VEQ6, STM32WB55VCQ6
STM32WB5Mxx STM32WB5MMGH6

STM32CubeWB 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 STM32WB Series

Kit Supported boards

P-NUCLEO-WB55.Nucleo: STM32WB55RG
P-NUCLEO-WB55
P-NUCLEO-WB55.USBDongle: STM32WB55CG
NA NUCLEO-WB35CE: STM32WB35CE

The P-NUCLEO-WB55 kit contains two boards to demonstrate STM32WB connectivity

functionalities:
• a Nucleo-68 board: P-NUCLEO-WB55.Nucleo
• a USB dongle: P-NUCLEO-WB55.USBDongle
The NUCLEO-WB35CE and P-NUCLEO-WB55.Nucleo are compatible with Adafruit® LCD
display Arduino® UNO shields which embed a microSD™ connector and a joystick in
addition to the LCD.

UM2550 Rev 3 13/30

29
STM32CubeWB firmware package overview UM2550

The Arduino® shield drivers are provided within the BSP component. Their usage is
illustrated by a demonstration firmware.
The STM32CubeWB firmware 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 this latter has
the same hardware features (LED, LCD display, buttons...).

3.2 Firmware package overview

The STM32CubeWB firmware solution is provided in one single zip package having the
structure shown in Figure 3.

Figure 3. STM32CubeWB firmware package structure

BSP driver

Drivers of external
components

Contains STM32WBxx CMSIS files

that define peripheral register
declarations, bit definitions and
address mapping STM32WBxx HAL
and LL drivers

Wireless personal
area network
middleware

Set of examples, applications and

demonstration organized by boards Open source
and provided with preconfigured middleware stacks
projects

Wirelss firmware
binaries

MS53625V1

1. The components files must not be modified by the user. Only the \Projects sources are eligible to changes
by the user.

14/30 UM2550 Rev 3

UM2550 STM32CubeWB firmware package overview

For each board, a set of examples are provided with pre-configured projects for EWARM,
MDK-ARM, and SW4STM32 tool-chains.
Figure 4 shows the project structure for the P-NUCLEO-WB55.Nucleo board.

Figure 4. Overview of STM32CubeWB examples

UM2550 Rev 3 15/30

29
STM32CubeWB firmware package overview UM2550

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.
The BLE folder contains typical BLE 5.0 use cases.
The Thread folder contains typical thread use cases.
The BLE_Thread folder contains an application illustrating the switching from BLE to
Thread and viceversa.
The BLE_ZigBee folder contains an application illustrating the switching from BLE to
Zigbee and viceversa.
The CKS folder contains an application which demonstrate how to use customer key
storage feature to store AES cryptographic keys in secure area.
The Mac_802_15_4 folder contains applications which demonstrate how to use MAC
802.15.4 Association and Data exchange.
The ZigBee folder contains applications to demonstrate the usage of clusters in
distributed or centralized ZigBee network.
Templates projects available in the Templates and Templates_LL directories allow to quickly
build any firmware application on a given board.
All examples have the same structure:
• \Inc folder that contains all header files.
• \Src folder for the sources code.
• \EWARM, \MDK-ARM, and \SW4STM32 folders contain the pre-configured project for
each toolchain.
• readme.txt describing the example behavior and needed environment to make it
working
• *.ioc file that allows users to open most of firmware examples within STM32CubeMX
(starting from STM32CubeMX 5.1)

16/30 UM2550 Rev 3

UM2550 Getting started with STM32CubeWB

4 Getting started with STM32CubeWB

4.1 Running your first example

This section explains how simple is to run a first example within STM32CubeWB. It uses as
illustration the generation of a simple LED toggle running on P-NUCLEO-WB55.Nucleo
board:
1. Download the STM32CubeWB firmware package. Unzip it into a directory of your
choice. Make sure not to modify the package structure shown in Figure 3. Note that it is
also recommended to copy the package at a location close to your root volume (e.g.
C\Eval or G:\Tests) because some IDEs encounter problems when the path length is
too long.
2. Browse to \Projects\NUCLEO-WB55-Nucleo\Examples.
3. Open \GPIO, then \GPIO_EXTI folders.
4. Open the project with your preferred toolchain. A quick overview on how to open, build
and run an example with the supported toolchains is given below.
5. Rebuild all files and load your image into target memory.
6. Run the example: each time you press the user pushbutton (SW1), LED2 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
a) Under the example folder, open \EWARM sub-folder
b) Launch the Project.eww workspace(a)
c) Rebuild all files: Project->Rebuild all
d) Load project image: Project->Debug
e) Run program: Debug->Go(F5)
• MDK-ARM
a) Under the example folder, open \MDK-ARM sub-folder
b) Launch the Project.uvprojx workspace(a)
c) Rebuild all files: Project->Rebuild all target files
d) Load project image: Debug->Start/Stop Debug Session
e) Run program: Debug->Run (F5).
• SW4STM32
a) Open the SW4STM32 toolchain
b) Click File->Switch Workspace->Other and browse to the SW4STM32
workspace directory
c) Click File->Import, select General->Existing Projects into Workspace and then
click Next
d) Browse to the SW4STM32 workspace directory and select the project
e) Rebuild all project files: select the project in the Project explorer window then
click the Project->build project menu
f) Run program: Run->Debug (F11)

UM2550 Rev 3 17/30

29
Getting started with STM32CubeWB UM2550

4.2 Developing your own application

4.2.1 Using STM32CubeMX to develop or update your application

In the STM32CubeWB MCU Package, 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 within STM32CubeMX requires
STM32CubeMX 5.1 or higher:
• After the installation of STM32CubeMX, open and eventually 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 delimited by comments USER CODE BEGIN and USER
CODE END. In case of a modification of the IP selection and setting, STM32CubeMX
updates the initialization part of the code but preserves the main application source
code.
For developing an own project in STM32CubeMX, follow the step-by-step process:
1. Select the STMicroelectronics STM32 microcontroller that matches the required set of
peripherals.
2. Configure each required embedded software thanks to 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 configuration selected. 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) user manual.
For a list of the Example projects available in STM32CubeWB, and their content, refer to the
STM32Cube firmware examples for STM32WB Series application note (AN5155).

a. The workspace name may change from one example to another.

18/30 UM2550 Rev 3

UM2550 Getting started with STM32CubeWB

4.2.2 HAL application

This section describes the steps required to create your own HAL application using
STM32CubeWB:
1. Create your project
To create a new project, you either start 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 P-NUCLEO-
WB55.Nucleo).
The Template project is providing empty main loop function, however it is a good
starting point to get familiar with project settings for STM32CubeWB. The template has
the following characteristics:
– It contains the source code of HAL, CMSIS and BSP drivers which are the minimal
components required to develop a code on a given board.
– It contains the include paths for all the firmware components.
– It defines the STM32WB device supported, thus allowing to configure the CMSIS
and HAL drivers accordingly.
– 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 to update the include
paths.
2. Add the necessary middleware to your project (optional)
The available middleware stacks are: FatFS, FreeRTOS™, USB Device, STMTouch
and STM32_WPAN. To know which source files must be added to the project file list,
refer to the documentation provided for each middleware. It is possible to look at the
applications available under \Projects\STM32xxx_yyy\Applications\<MW_Stack>
(where <MW_Stack> refers to the middleware stack, such as USB_Device) 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, it 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

UM2550 Rev 3 19/30

29
Getting started with STM32CubeWB UM2550

information to know 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 do the following tasks:
a) Configuration of the Flash prefetch and SysTick interrupt priority (through macros
defined in stm32wbxx_hal_conf.h).
b) Configuration of the SysTick to generate an interrupt every millisecond at the
SysTick interrupt priority TICK_INT_PRIO defined in stm32wbxx_hal_conf.h.
c) Setting of NVIC Group Priority to 0.
d) Call of HAL_MspInit() callback function defined in stm32wbxx_hal_msp.c user
file to perform global low-level hardware initializations.
5. Configure the system clock
The system clock configuration is done by calling the two APIs described below:
a) 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.
b) HAL_RCC_ClockConfig(): this API configures the system clock source, the
Flash memory latency and AHB and APB prescalers.
6. 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 you plan to use peripheral interrupt or
DMA.
d) In your main.c file, initialize the peripheral handle structure then call the function
HAL_PPP_Init() to initialize your peripheral.
7. Develop your application
At this stage, your system is ready and you start developing your application code.
– The HAL provides intuitive and ready-to-use APIs to configure the peripheral. It
supports polling, interrupts and DMA programming model, to accommodate any
application requirements. For more details on how to use each peripheral, refer to
the rich examples set provided in the STM32CubeWB MCU package.
– If your application has some real-time constraints, you find a large set of examples
showing how to use FreeRTOS™ and integrate it with all middleware stacks
provided within STM32CubeWB. This is a good starting point to develop your
application.
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 will be blocked. Functions affecting

20/30 UM2550 Rev 3

UM2550 Getting started with STM32CubeWB

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.

4.2.3 LL application
This section describes the steps needed to create your own LL application using
STM32CubeWB.
1. Create your project
To create a new project you 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 P-NUCLEO-WB55.Nucleo).
The Template project provides an empty main loop function, however it is a good
starting point to get familiar with project settings for STM32CubeWB.
Template main characteristics are the following:
– It contains the source codes of the LL and CMSIS drivers which are the minimal
components needed to develop code on a given board.
– It contains the include paths for all the required firmware components.
– It selects the supported STM32WB device and allows to configure the CMSIS and
LL drivers accordingly.
– 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 or to application note “STM32Cube
firmware examples for STM32WB Series” (AN5155).
b) 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 stm32wbxx_it.h file
– Replace the stm32wbxx_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.

UM2550 Rev 3 21/30

29
Getting started with STM32CubeWB UM2550

– 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.
Thanks to these adaptations, the example should be functional on the targeted board.

4.2.4 Installing and running the STM32CubeUpdater program

Follow the sequence below to install and run the STM32CubeUpdater:
1. To launch the installation, double-click the SetupSTM32CubeUpdater.exe file.
2. Accept the license terms and follow the different installation steps.
3. Upon successful installation, STM32CubeUpdater becomes available as an
STMicroelectronics program under Program Files and is automatically launched. The
STM32CubeUpdater icon appears in the system tray. Right-click the updater icon and
select ‘Updater Settings’ to configure the Updater connection and whether to perform
manual or automatic checks. For more details on Updater configuration, refer to
section 3 of STM32CubeMX for STM32 configuration and initialization C code
generation (UM1718) user manual.

22/30 UM2550 Rev 3

UM2550 How to flash the wireless coprocessor binary

5 How to flash the wireless coprocessor binary

The STM32CubeWB firmware package contains several wireless stack binaries located
under Projects\STM32WB_Copro_Wireless_Binaries.

STM32WB5x (Projects\STM32WB_Copro_Wireless_Binaries\STM32WB5x)
The supported binaries are the following:
• stm32wb5x_BLE_Stack_full_fw.bin
– Full BLE stack, certified 5.0: link layer, HCI, L2CAP, ATT, SM, GAP and GATT
database
– BT SIG certification listing: declaration ID D042164
• stm32wb5x_BLE_Stack_light_fw.bin
– Erase/Write Flash memory of wireless stack non volatile memory while BLE link is
active (min interval 28 ms)
– Fix IFS (inter frame spacing) sometimes longer than 152 μs
– Wireless BLE stack light configuration (slave only): GAP peripheral / LL slave,
GATT server, Data length extension, Double LL slave
• stm32wb5x_BLE_HCILayer_fw.bin
– HCI layer, only mode 5.0 certified: link layer and HCI
– BT SIG certification listing: declaration ID D042213
• stm32wb5x_Thread_FTD_fw.bin
– Full Thread Device, certified v1.1
Usage: Leader, Router and End Device Thread roles (full featured except for Border
Router)
• stm32wb5x_Thread_MTD_fw.bin
– Minimal Thread Device, certified v1.1.
Usage: End Device and Sleepy End Device Thread roles
• stm32wb5x_BLE_Thread_fw.bin
– Static Concurrent Mode BLE Thread, supporting full BLE stack certified 5.0 and
Full Thread Device certified v1.1
• stm32wb5x_Mac_802_15_4_fw.bin
– MAC API based on the latest official IEEE Std 802.15.4-2011
Usage: MAC FFD and RFD devices
• stm32wb5x_rfmonitor_phy802_15_4_fw.bin
– Dedicated firmware binary to be used with STM32CubeMonitor-RF application.
Refer to STM32CubeMonitor-RF software tool for wireless performance
measurements (UM2288) user manual to get application details.
• stm32wb5x_Zigbee_FFD_Full_fw.bin
– Zigbee Compliant Platform certified.
Supports: full function device (FFD)
• stm32wb5x_BLE_Zigbee_FFD_static_fw.bin
– Static Concurrent Mode BLE Zigbee
Supports: full BLE Stack 5.0 certified and Zigbee FFD compliant platform certified

UM2550 Rev 3 23/30

29
How to flash the wireless coprocessor binary UM2550

• stm32wb5x_FUS_fw_1_0_2.bin
– Firmware Upgrade Services (FUS)
This binary is the utility to flash the Wireless Coprocessor Binaries.
FUS version v1.0.2
• stm32wb5x_FUS_fw.bin
– FUS (firmware upgrade Ssrvices)
This binary is the utility to flash the wireless coprocessor binaries.
Latest version of the FUS

STM32WB3x (Projects\STM32WB_Copro_Wireless_Binaries\STM32WB3x)
The supported binaries are the following:
• stm32wb3x_BLE_Stack_full_fw.bin
– Full BLE Stack 5.0 certified: Link Layer, HCI, L2CAP, ATT, SM, GAP and GATT
database
– BT SIG Certification listing: Declaration ID D042164
• stm32wb3x_BLE_Stack_light_fw.bin
– Wireless BLE stack light configuration (slave only): GAP peripheral / LL slave,
GATT server, Data length extension
• slavestm32wb3x_BLE_HCILayer_fw.bin
– HCI Layer only mode 5.0 certified: Link Layer, HCI
– BT SIG Certification listing: Declaration ID D042213
• stm32wb3x_Mac_802_15_4_fw.bin
– MAC API is based on latest official IEEE Std 802.15.4-2011
Usage: MAC FFD and RFD devices
• stm32wb3x_Thread_FTD_fw.bin
– Full Thread Device certified v1.1
Usage: Leader / Router / End Device Thread role (full features excepting Border
Router)
• stm32wb3x_Thread_MTD_fw.bin
– Minimal Thread Device certified v1.1
Usage: End Device and Sleepy End Device Thread role
Follow the steps below to flash the wireless coprocessor binary into the device memory
(inside the below procedure, the references to binaries name and installation address are
provided in the section Main Changes of the release note under
Projects/STM32WB_Copro_Wireless_Binaries/STM32WB5x/Release_Notes.html or
Projects/STM32WB_Copro_Wireless_Binaries/STM32WB3x/Release_Notes.html. Those
values depends on the versions of your binaries, their name and your device):
1. Use STM32CubeProgrammer version 2.0 or higher (refer to ST firmware upgrade
services for STM32WB Series (AN5185)
The STM32CubeProgrammer software is available as command line interface (CLI).
It gives access to the firmware upgrade service (FUS) through the bootloader.
2. Access to bootloader USB interface (system Flash memory)
This is achieved by connecting BOOT0 pin to VDD.
For P-NUCLEO-WB55.Nucleo:

24/30 UM2550 Rev 3

UM2550 How to flash the wireless coprocessor binary

– Add a jumper between CN7.5 (VDD) and CN7.7 (BOOT0).

– Power on the board via USB_USER and J2 jumper (USB_MCU).
For P-NUCLEO-WB55.USBDongle:
– Move SW2 switch to BOOT0 position.
– Connect P-NUCLEO-WB55.USBDongle to you PC USB port.
For NUCLEO-WB35CE: Not applicable for this board.
3. Delete the current wireless stack by executing the following command line
STM32_Programmer_CLI.exe -c port=usb1 -fwdelete
4. Read and upgrade FUS Version
For STM32WB5x:
STM32_Programmer_CLI.exe -c port=usb1 -r32 0x20030030 1
– 0x20030030 : 00050300: FUSv0.5.3 => Must be updated using step 5.
– 0x20030030 : 01000100 or 01000200: FUSv1.0.x => Updated, you can download
the new wireless stack using step 6.
For STM32WB3x:
No FUS version available to upgrade.
5. Download the new FUS
STM32_Programmer_CLI.exe -c port=usb1 -fwupgrade[FUS_Binary] [Install@]
firstinstall=0
Check firmware upgrade services binary table for Install@ parameter depending of the
binary.
6. Download new wireless stack:
STM32_Programmer_CLI.exe -c port=usb1
-fwupgrade[Wireless_Coprocessor_Binary] [Install@] firstinstall=0
check Wireless Coprocessor Binary Table for Install@ parameter depending of the
binary.
7. Revert step 2 procedure to put back device in normal mode.

UM2550 Rev 3 25/30

29
FAQ UM2550

6 FAQ

6.1 What is the license scheme for the STM32CubeWB

firmware?
The HAL is distributed under a non-restrictive BSD (Berkeley Software Distribution) license.
The middleware stacks made by STMicroelectronics (USB Device Libraries, STemWin,
STM32_WPAN) come with a licensing model allowing easy reuse, provided it runs on an
STMicroelectronics device.
The middleware based on well-known open-source solutions (FreeRTOS™ and FatFS)
have user-friendly license terms. For more details, refer to the license agreement of each
middleware.

6.2 What boards are supported by the STM32CubeWB firmware

package?
The STM32CubeWB firmware package provides BSP drivers and ready-to-use examples
for the following STM32WB boards:
• P-NUCLEO-WB55.Nucleo
• P-NUCLEO-WB55.USBDongle
• NUCLEO-WB35CE

6.3 Are any examples provided with the ready-to-use toolset

projects?
Yes. STM32CubeWB provides a rich set of examples and applications. They come with the
pre-configured projects for IAR™, Keil® and GCC-based toolchains.

6.4 Is there any link with Standard Peripheral Libraries?

The STM32Cube 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 peripheral common features rather than hardware. Their higher
abstraction level allows defining a set of user-friendly APIs that are easily portable from
one product to another.
• The LL drivers offer low-layer APIs at registers level. They are organized in a simpler
and clearer way than 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 STM32Cube LL drivers, since each SPL
API has its equivalent LL API(s).

26/30 UM2550 Rev 3

UM2550 FAQ

6.5 Does the HAL layer take benefit from 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.6 How are the product/peripheral specific features managed?

The HAL drivers offer extended APIs, i.e. specific functions as add-ons to the common API
to support features available on some products/lines only.

6.7 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.8 When should I use HAL 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 APIs at registers level, with a better optimization but less
portability. They require a deep knowledge of product/IPs specifications.

6.9 How can I include LL drivers in my environment?

Is there any LL configuration file as for HAL?
There is no configuration file. Source code shall directly include the necessary
stm32wbxx_ll_ppp.h file(s).

6.10 Can I use HAL and LL drivers together? If yes, what are the
constraints?
It is possible to use both HAL and LL drivers. One handles the IP initialization phase with
HAL and then manages 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 Examples_MIX example.

UM2550 Rev 3 27/30

29
FAQ UM2550

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

6.12 Why are SysTick interrupts not enabled on LL drivers?

When using LL drivers in standalone mode, you do not need to enable SysTick interrupts
because they are not used in LL APIs, while HAL functions requires SysTick interrupts to
manage timeouts.

6.13 How are LL initialization APIs enabled?

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

28/30 UM2550 Rev 3

UM2550 Revision history

7 Revision history

Table 3. Document revision history

Date Revision Changes

06-Feb-2019 1 Initial release.

24-Jun-2019 2 Updated Table 1: Macros for STM32WB Series.
Added:
– ZigBee reference in Introduction, Section 1:
STM32CubeWB main features
– Section 2.2.2: ZigBee stack
Updated:
– Table 1: Macros for STM32WB Series, Table 2:
28-Feb-2020 3 Boards for STM32WB Series
– Figure 3: STM32CubeWB firmware package
structure, Figure 4: Overview of STM32CubeWB
examples
– Section 3.2: Firmware package overview, Section 5:
How to flash the wireless coprocessor binary,
Section 6.2: What boards are supported by the
STM32CubeWB firmware package?

UM2550 Rev 3 29/30

29
 UM2550

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

30/30 UM2550 Rev 3