STM32CubeF4GettingStarted
STM32CubeF4GettingStarted
User manual
Getting started with STM32CubeF4 firmware package
for STM32F4 Series
Introduction
The STMCube™ initiative was originated by STMicroelectronics to help reduce development
effort, time and cost. STM32Cube covers the STM32 portfolio.
STM32Cube Version 1.x includes:
• STM32CubeMX, a graphical software configuration tool that allows generation of C
initialization code using graphical wizards.
• A comprehensive embedded software platform, delivered per series (such as
STM32CubeF4 for the STM32F4 series)
– The STM32Cube HAL STM32 abstraction-layer embedded software, ensuring
maximized portability across the STM32 portfolio.
– Low Layer APIs (LL) offering a fast, lightweight, expert-oriented layer which is
closer to the hardware than the HAL. The LL APIS are available for a set of
peripherals.
– A consistent set of middleware components, such as RTOS, USB, TCP/IP and
graphics.
– All embedded software utilities, with a full set of examples.
This user manual describes how to get started with the STM32CubeF4 firmware package.
Section 1 describes the main features of STM32CubeF4 firmware, part of the STMCube™
initiative.
Section 2 and Section 3 provide an overview of the STM32CubeF4 architecture and
firmware package structure.
Contents
5 FAQs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6 Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
List of tables
List of figures
STM32CubeF4 gathers together, in a single package, all the generic embedded software
components required to develop an application on STM32F4 microcontrollers. In line with
the STMCube™ initiative, this set of components is highly portable, not only within the
STM32F4 series but also to other STM32 series.
STM32CubeF4 is fully compatible with the STM32CubeMX code generator that allows the
user to generate 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 an open-source BSD license for user convenience.
STM32CubeF4 package also contains a set of middleware components with the
corresponding examples. They come with very permissive license terms:
• Full USB host and device stack supporting many classes:
– Host classes: HID, MSC, CDC, Audio, MTP
– Device classes: HID, MSC, CDC, Audio, DFU
• Graphics:
– STemWin, a professional graphical stack solution available in binary format and
based on the emWin solution from the ST partner SEGGER
– LibJPEG, an open source implementation on STM32 for JPEG images encoding
and decoding
• CMSIS-RTOS implementation with FreeRTOS open source solution
• FAT file system based on open source FatFS solution
• TCP/IP stack based on open source LwIP solution
• SSL/TLS secure layer based on open source mbedTLS
A demonstration implementing all these middleware components is also provided in the
STM32CubeF4 package.
)$7ILOH &06,6
7&3,3 86% *UDSKLFV 5726
V\VWHP
0LGGOHZDUHOHYHO 8WLOLWLHV
7KHVHWRIPLGGOHZDUHFRPSRQHQWVGHSHQGVRQWKHSURGXFW6HULHV 069
The STM32CubeF4 firmware solution is built around three independent levels that can
easily interact with each other as described in the Figure 2 below:
>ĞǀĞůϮ (YDOERDUGDQG'LVFRYHU\.LWGHPRQVWUDWLRQ
$SSOLFDWLRQV
>ĞǀĞůϭ
/LEUDU\DQGSURWRFROEDVHGFRPSRQHQWV )DW)6)UHH572686%
+RVW86%'HYLFH(WKHUQHW«
([DPSOHV
%63GULYHUV
>ĞǀĞůϬ
,ĂƌĚǁĂƌĞĂďƐƚƌĂĐƚŝŽŶůĂLJĞƌ;,>Ϳ
ŽƌĞĚƌŝǀĞƌƐ;ŽƉƚŝŽŶĂůͿ >Žǁ>ĂLJĞƌ;>>Ϳ
,>
06Y9
initialize and configure the peripheral, manage data transfer based on polling, interrupt
or DMA process, and manage communication errors that may raise during
communication. The HAL drivers APIs are split in two categories: generic APIs which
provide common and generic functions to all the STM32 Series and extension APIs
which provide specific and customized functions for a specific family or a specific part
number.
• Basic peripheral usage examples: this layer contains examples of basic operation of
the STM32F4 peripherals using only the HAL and/or the Low-Layer driver APIs as well
as the BSP resources.
• Low Layer (LL): The low layer APs provide low-level APIs at register level, with better
optimization but less portability. They require a deep knowledge of MCU and peripheral
specificatins.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 those
requiring heavy software configuration and/or complex upper-level stack (such as
FSMC, USB or SDMMC).
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.
Level 1: this level is divided into two sub-layers:
• Middleware components: a set of libraries covering USB host and device libraries,
STemWin, LibJPEG, FreeRTOS, FatFS, LwIP, and mbedTLS. Horizontal interactions
between the components of this layer are done directly by calling the feature APIs while
the vertical interaction with the low-level 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 the microSD™ drive or the USB mass storage
class.
The main features of each middleware component are as follows:
USB host and device libraries
– Several USB classes supported (Mass-Storage, HID, CDC, DFU, AUDIO, MTP)
– Supports multi packet transfer features: allows sending big amounts of data
without splitting them into max packet size transfers
– Uses configuration files to change the core and the library configuration without
changing the library code (Read Only)
– Includes 32-bit aligned data structures to handle DMA-based transfer in High-
speed modes
– Supports multi USB OTG core instances from user level through configuration file
(allows operation with more than one USB host/device peripheral)
– RTOS and standalone operation
– The link with low-level driver is done through an abstraction layer using the
configuration file to avoid any dependency between the library and the low-level
drivers
STemWin graphical stack
– Professional grade solution for GUI development based on the emWin solution by
SEGGER
– Optimized display drivers
– Software tools for code generation and bitmap editing (STemWin Builder…)
LibJPEG
– Open source standard
– C implementation for JPEG image encoding and decoding.
FreeRTOS
– Open source standard
– CMSIS compatibility layer
– Tickless operation during low-power mode
– Integration with all STM32Cube middleware modules
FAT File system
– FATFS FAT open source library
– Long file name support
– Dynamic multi-drive support
– RTOS and standalone operation
– Examples with microSD and USB host mass-storage class
LwIP TCP/IP stack
– Open source standard
– RTOS and standalone operation
• 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.
Level 2: This level is composed of a single layer which is a global real-time and graphical
demonstration based on the middleware service layer, the low-level abstraction layer and
the applications that make basic use of the peripherals for board-based functions.
STM32CubeF4 features a rich set of examples and demonstrations at all levels making it
easy to understand and use HAL drivers and/or middleware components. These examples
run on the STMicroelectronics boards listed in Table 2 below:
STM32F412ZG-Nucleo STM32F412Zx
STM32F413ZH-Nucleo STM32F413ZH
STM32F413H-Discovery STM32F413ZH
STM32F4 supports both Nucleo-64 and Nucleo-144 boards. These boards support Adafruit
LCD display, the Arduino™ UNO shields which embed a microSD connector and a joystick
in addition to the LCD.
The Arduino™ shield drivers are provided within the BSP component. Their usage is
illustrated by a demonstration firmware.
The STM32CubeF4 firmware is able to run on any compatible hardware. If the user’s board
has the same hardware features as the ST board (LED, LCD display, push-buttons and
others), the user has just to update the BSP drivers to port the provided examples on his
board.
&RQWDLQV
670)[[
&06,6ILOHVWKDW
GHILQHV
3HULSKHUDO V
UHJLVWHUV
GHFODUDWLRQVELWV
GHILQLWLRQDQGWKH %63GULYHUVIRUWKH
DGGUHVVPDSSLQJ VXSSRUWHGERDUGV
67HP:LQ
SURIHVVLRQDOVWDFN 670)[[+$/
FRPLQJIURP DQG//GULYHUV
6(**(5DQG
DYDLODEOHLQELQDU\
IRUP
86%'HYLFH
86%+RVW/LEUDU\ /LEUDU\VXSSRUWLQJ
VXSSRUWLQJERWK ERWK27*)6DQG
27*)6DQG+6 +6FRUHVDQG
FRUHVDQGRIIHULQJ RIIHULQJWKH
WKHIROORZLQJ IROORZLQJFODVVHV
FODVVHV+,'06& +,'06&&'&
&'&$XGLRDQG $XGLRDQG')8
073
6HWRIH[DPSOHV
RUJDQL]HGE\ERDUGDQG
SURYLGHGZLWK
0LVFHOODQHRXV
SUHFRQILJXUHGSURMHFWV
XWLOLWLHV
:,1GLUHFWRU\
FRQWDLQV:LQGRZV
EDVHGVLPXODWLRQ
SURMHFWIRU67HP:LQ
06Y9
For each board, a set of examples are provided with preconfigured projects for EWARM,
MDK-ARM™, TrueSTUDIO® and SW4STM32 toolchains.
Figure 4 shows the project structure for the STM32F411RE-Nucleo board. The structure is
identical for other boards.
The examples are classified depending on the STM32Cube level they apply to, and are
named as follows:
• Examples in level 0 are:
– Examples using HAL drivers
– Examples_LL using LL drivers
– Examples_MIX, using a mix of HAL and LL drivers, without any middleware
component
• Examples in level 1 are called Applications and provide typical use cases of each
middleware component
• Examples in level 2 are called Demonstration and implement the HAL, BSP and
middleware components
A template project is provided to allow users to build quickly 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, \TrueSTUDIO and \SW4STM32 folders contain the
preconfigured project for each toolchain
• readme.txt describes the example behavior and the environment required to make it
work
06Y9
The Table 3 provides the number of examples, applications and demonstrations available
for each board.
STM324x9I-EVAL 87 NA NA 55 1
STM324xG-EVAL 72 NA NA 53 1
STM32F4-Discovery 27 NA NA 3 1
STM32F401-Discovery 24 NA NA 3 1
STM32F401RE-Nucleo 7 NA NA NA NA
STM32F411RE-Nucleo 9 62 12 NA 1
STM32F411E-Discovery 24 NA NA 3 1
STM32F429I-Discovery 30 NA NA 11 1
STM32F429ZI-Nucleo 27 7 1 7 1
STM32446E-EVAL 71 NA NA 38 1
STM32F446ZE-Nucleo 27 NA NA 6 1
STM32469I-EVAL 94 NA NA 43 1
STM32469I-Discovery 46 NA NA 25 1
STM32F410xx-Nucleo 16 2 NA 1 NA
STM32F412G-Discovery 50 NA NA 24 1
STM32F412ZG-Nucleo 42 NA NA 10 1
STM32F413ZH-Nucleo 48 NA NA 18 1
STM32F413H-Discovery 27 NA NA 20 1
the project folder). The configuration file provides enough information to know the effect
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 needs
to call the HAL_Init() API to initialize the HAL library, which does the following:
a) Configures the Flash prefetch, instruction and data caches (user-configurable by
macros defined in stm32f4xx_hal_conf.h)
b) Configure the SysTick to generate an interrupt every 1ms. The SysTick is clocked
by the HSI (default configuration after reset)
c) Sets NVIC Group Priority to 4
d) Calls the HAL_MspInit() callback function defined in user file
stm32f4xx_hal_msp.c to do the global low-level hardware initialization
5. Configure the system clock: the system clock configuration is done by calling these
two APIs:
a) HAL_RCC_OscConfig(): configures the internal and/or external oscillators, PLL
source and factors. The user can choose to configure one oscillator or all
oscillators. If the system must not run at high frequency, the user can skip the PLL
configuration
b) HAL_RCC_ClockConfig(): configures the system clock source, Flash latency and
AHB and APB prescalers
6. Peripheral initialization
a) Start by writing the peripheral HAL_PPP_MspInit function. For this function,
proceed as follows:
– Enable the peripheral clock.
– Configure the peripheral GPIOs.
– Configure DMA channel and enable DMA interrupt (if needed).
– Enable peripheral interrupt (if needed).
b) Edit the stm32f4xx_it.c to call the required interrupt handlers (peripheral and
DMA), if needed.
c) Write process complete callback functions if the user plans to use peripheral
interrupt or DMA.
d) In the main.c file, initialize the peripheral handle structure, then call the function
HAL_PPP_Init() to initialize the peripheral.
7. Develop an application process: at this stage, the system is ready and the user can
start developing the application code.
a) The HAL provides intuitive and ready-to-use APIs for configuring the peripheral,
and supports polling, interrupt and DMA programming models, to accommodate
any application requirements. For more details on how to use each peripheral,
refer to the rich example set provided.
b) If the application has some real-time constraints, the user can find a large set of
examples showing how to use the FreeRTOS and integrate it with the middleware
stacks provided in the STM32CubeF4. It can be a good starting point for a first
development.
Note: In the default HAL implementation, the SysTick timer is the timebase source. It is used to
generate interrupts at regular time intervals. If HAL_Delay() is called from peripheral ISR
process, the SysTick interrupt must have 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.
4.2.2 LL application
This section describes the steps needed to create your own LL application using
STM32CubeF4.
1. Create your project
To create a new project, you can 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 STM32F411RE-Nucleo).
The Template project provides an empty main loop function, however it is a good
starting point to get familiar with project settings for STM32CubeF4.
The main template characteristics are as follows:
– It contains the source code of LL and CMSIS drivers, that are the minimal
components to develop a code on a given board.
– It contains the include paths for all the required firmware components.
– It selects the supported STM32F4 device and allows configuring 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 an LL example To find the board on which LL examples are deployed, refer to
the list of LL examples in STM32CubeProjectsList.html, to Table 3: Number of
examples available for each board.
b) Port the LL example
– Copy/paste the Templates_LL folder to keep the initial source or directly update
the existing Templates_LL project.
– Then LL example porting consists mainly 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 stm32f4xx_it.h file
– Replace stm32f4xx_it.c file
– Replace 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 the LED definition, replace all LEDx occurrences with another LEDy available
in main.h.
Thanks to these adaptations, the example should be functional on the targeted board.
• Right-click the updater icon and select Updater Settings to configure the Updater
connection and whether to perform manual or automatic checks (see STM32CubeMX
User guide - UM1718 section 3 - for more details on Updater configuration).
5 FAQs
Does the HAL take benefit from interrupts or DMA? How can this be
controlled?
Yes, it does. The HAL supports three API programming models: polling, interrupt and DMA
(with or without interrupt generation).
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 can handle the IP initialization phase with
HAL and then manage the I/O operations with LL drivers.
The major difference between HAL and LL is that HAL drivers require the creation and use
of handles for operation management, while LL drivers operate directly on peripheral
registers. Mixing HAL and LL is illustrated in Examples_MIX example.
6 Revision history
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.
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. 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.