STM32CubeMX
17 Tutorial 7 - Using the X-Cube-BLE1 software pack ¶
9. Click Open project. The Oryx software components are displayed in the generated project (see Figure 685).
Figure 685. Generated project with third party pack components
17 Tutorial 7 – Using the X-Cube-BLE1 software pack
This tutorial demonstrates how to achieve a functional project using the X-Cube-BLE1 software pack.
Below the prerequisites to run this tutorial:
• Hardware: NUCLEO-L053R8, X-NUCLEO-IDB05A1 and mini-USB cable (see Figure 686)
• Tools: STM32CubeMX, IDE (Atollic ® or any other toolchain supported by STM32CubeMX)
• Embedded software package: STM32CubeL0 (version 1.10.0 or higher), X-Cube-BLE1
1.1.0 (see Figure 687).
• Mobile application (see Figure 688): STMicroelectronics BlueNRG application for iOS ® or Android ™
Figure 687. Embedded software packages
Proceed as follows to install and run the tutorial:
1. Check STM32CubeMX Internet connection:
a) Select the Help > Updater Settings menu to open the updater window.
b) Verify in the Connection tab that the Internet connection is configured and up.
2. Install the required embedded software packages (see Figure 689):
a) Select the Help > Manage Embedded software packages menu to open the embedded software package manager window.
b) Click the Refresh button to refresh the list with the latest available package versions.
c) Select the STM32Cube MCU Package tab and check that the STM32CubeL0 firmware package version 1.10.0 or higher is installed (the checkbox must be green). Otherwise select the checkbox and click Install now.
d) Select the STMicrolectronics tab and check that the X-Cube-BLE1 software pack version 1.0.0 is installed (checkbox must be green). Otherwise, select the checkbox and click Install now.
Figure 689. Installing Embedded software packages
3. Start a new project:
a) Select New Project to open the new project window.
b) Select the Board selector tab.
c) Select Nucleo64 as board type and STM32L0 as MCU Series.
d) Select the NUCLEO-L053R8 from the resulting board list (see Figure 690).
e) Answer No when prompted to initialize all peripherals in their default mode (see Figure 691).
Figure 690. Starting a new project - selecting the NUCLEO-L053R8 board
4. Add X-Cube-BLE1 components to the project:
a) Click Additional Software from Pinout & Configuration view to open the Additional Software component Selection window.
b) Select the relevant components (see Figure 692)
The Application group comes with a list of applications: the C files implement the application loop, that is the Process() function. From the Application group, select the SensorDemo application.
Select the Controller and Utils components
Select the Basic variant for the HCI_TL component . The Basic variant provides the STMicroelectronics implementation of the HCI_TL API while the template option requires users to implement their own code.
Select the UserBoard variant as HCI_TL_INTERFACE component. Using the UserBoard option generates the <boardname>_bus.c file, that is nucleo_l053r8_bus.c for this tutorial, while the template option generates the custom_bus.c file and requires users to provide their own implementation.
Refer to the X-Cube-BLE1 pack documentation for more details on software components.
Click OK to apply the selection to the project and close the window. The left panel Additional Software section is updated accordingly.
Figure 692. Selecting X-Cube-BLE1 components
5. Enable peripherals and GPIOs from the Pinout tab (see Figure 693):
a) Configure USART2 in Asynchronous mode.
b) Configure SPI1 in Full-duplex master mode.
c) Left-click the following pins and configure them for the required GPIO settings:
PA0: GPIO_EXTI0
PA1: GPIO_Output
PA8: GPIO_Output
d) Enable Debug Serial Wire under SYS peripheral.
Figure 693. Configuring peripherals and GPIOs
6. Configure the peripherals from the Configuration tab:
a) Click the NVIC button under the System section to open the NVIC configuration window. Enable EXTI line 0 and line 1 interrupts and click OK (see Figure 694).
b) Click the SPI button under the Connectivity section to open the SPI configuration window. Check that the data size is set to 8 bits and the prescaler value to 16 so that HCLK divided by the prescaler value is less or equal to 8 MHz.
c) Click USART2 under the Connectivity section to open the Configuration window and check the following parameter settings:
Under Parameter Settings:
Baud rate: 115200 bits/s
Word length: 8 bits (including parity) Parity: none
Stop bits: 1
Under GPIO Settings:
User labels: USART_TX and USART_RX
Figure 694. Configuring NVIC interrupts
7. Enable and configure X-Cube-BLE1 pack components from the Pinout & Configuration view:
a) Click the pack items from the left panel to show the mode and configuration tabs.
b) Click the check boxes from the Mode panel to enable X-Cube-BLE1, the configuration panel appears showing the parameters to configure. An orange triangle indicates that some parameters are not configured. It turns into a green check mark once all parameters are correctly configured (see Figure 695).
c) Leave the Parameter Settings Tab unchanged.
d) Go the Platform settings tab, configure the connection with the hardware resources as indicated in Figure 695 and Table 29.
Table 29. Connection with hardware resources
|
Name |
IPs or components |
Found solutions |
|
BUS IO driver |
SPI in Full-duplex master mode |
SPI1 |
|
EXTI Line |
GPIO:EXTI |
PA0 |
|
CS Line |
GPIO:output |
PA1 |
|
Reset Line |
GPIO:output |
PA8 |
|
BSP LED |
GPIO:output |
PA5 |
|
BSP Button |
GPIO:EXTI |
PC13 |
|
BSP USART |
USART in Asynchronous mode |
USART2 |
Check that the icon turns to . Click OK to close the Configuration window .
Figure 695. Enabling X-Cube-BLE1
Generate the SensorDemo project:
a) Click ** to generate the code. The **Project Settings window opens if the project has not yet been saved.
b) Click ** ** to generate the code once the project settings have
been properly configured (see Figure 696). When the generation is complete, a dialog window requests to open the project folder (Open Folder) or to open the project in IDE toolchain (Open Project). Select Open Project (see Figure 697).
Figure 696. Configuring the SensorDemo project
18 Creating LPBAM projects
18.1 LPBAM overview
Disclaimer: to learn about the LPBAM mode and its usage, it is recommended to read the LPBAM application note available on www.st.com, and the LPBAM utility getting started guide located under the Utilities folder of the STM32Cube firmware package.
18.1.1 LPBAM operating mode
LPBAM stands for low power background autonomous mode. It is an operating mode that allows peripherals to be functional and autonomous independently from power modes and without any software running. It is performed thanks to a hardware subsystem embedded in STM32 products. Thanks to DMA transfers in Linked-list mode, the LPBAM subsystem can chain different actions to build a useful functionality (peripheral configurations and transfers). Optionally, it can generate asynchronous events and interrupts. It operates without any CPU intervention. Consequently, the two major benefits from using the LPBAM subsystem mechanisms are an optimized power consumption, and an offloaded CPU.
18.1.2 LPBAM firmware
The LPBAM firmware has been designed to help users create LPBAM applications: the LPBAM utility is a set of modular drivers located under the Utilities folder of the STM32Cube firmware package. Each module comes as a pair of C file that provides the APIs needed to build an application scenario. Each module manages the configurability and the data transfers for a given peripheral. The LPBAM utility is designed to be compatible with any STM32 devices supporting LPBAM subsystem mechanisms through a configuration module: it requires a configuration file stm32_lpbam_conf.h aligned with the application needs. The LPBAM utility has a single application entry point, the stm32_lpbam.h, that must be included in the project.
18.1.3 Supported series
The LPBAM firmware supports STM32U575/585, STM32U595/5A5 and STM32U599/5A9 products, for projects with or without TrustZone activated.
STM32CubeMX 6.5.0 introduces LPBAM for projects without TrustZone activated on the
STM32U575/585 product line: users can create LPBAM applications for their project using STM32CubeMX LPBAM Scenario & Configuration view and generate the corresponding code. The generated C project embeds the LPBAM firmware.
STM32CubeMX 6.6.0 adds LPBAM support for projects with TrustZone activated.
18.1.4 LPBAM design
It is recommended to use LPBAM to save power and offload the CPU.
• The LPBAM mechanism supports the following set of peripherals on the Smart Run Domain: ADC4, COMP1/2, DAC1, I2C3, LPDMA1, LPGPIO, LPTIM1/2/3, LPUART1, OPAMP1/2, SPI3, VREFBUF.
• According to the LPDMA implementation in the Smart run domain, the LPBAM has access only to SRAM4.
• The LPBAM mechanism implementation can run autonomously until Stop2 mode. • To reach the lowest power consumption, the system power usage, the system clock and the autonomous peripheral kernel clock can be configured:
18.1.5 LPBAM project support in STM32CubeMX
An LPBAM project is composed of a main project, and of one or more LPBAM applications.
Figure 698. LPBAM project
The “Main project” contains the “SoC and IPs configuration” at initialization time and a runtime description of the main application. STM32CubeMX allows to describe the “SOC and IPs Configuration” part.
Each LPBAM application contains a “SoC and IPs configuration” and a runtime description. STM32CubeMX allows to describe both.
STM32CubeMX generated code for “SoC and IPs configurations” uses the STM32Cube HAL and/or LL APIs, for both the main project and the LPBAM application. The code generated for the LPBAM application runtime uses the LPBAM firmware API.
Figure 699 is an example of what can be executed at runtime for a simple LPBAM project composed of the main application and of one LPBAM application.
Figure 699. Project timeline
18.2 Creating an LPBAM project
18.2.1 LPBAM feature availability
When a project with LPBAM feature capability is opened, a dedicated entry is shown in the user interface (see Figure 700). The feature is optional and when it is not used, it has no impact on the generated project.
18.2.2 Describing an LPBAM project
Describing an LPBAM project in STM32CubeMX consists in describing the main project using STM32CubeMX main project page, and one or more LPBAM applications using the dedicated LPBAM Scenario & Configuration page.
Starting with STM32CubeMX 6.5:
• Create a project by selecting an MCU or board part number from the STM32U575/585 product line.
• Do not activate TrustZone for the project.
• Click “LPBAM Scenario & Configuration” ribbon to view LPBAM dedicated page.
The LPBAM context is highlighted with a pink border. You can switch back and forth between the main project configuration and the LPBAM Scenario & Configuration by clicking the corresponding ribbon.
Figure 701. LPBAM Scenario & Configuration view
18.2.3 Managing LPBAM applications in a project
When entering the LPBAM Scenario & Configuration view, you must first add an LPBAM application.
Adding, removing, renaming, and switching between LPBAM applications is done from the left panel under the LPBAM manager section.
To add the first LPBAM application, click “Add Application”:
• If the default name is kept, the application “LpbamApp1” is created.
• The first Queue “Queue1” of LpbamApp1 is created.
• The configuration views (LPBAM scenario, pinout & ip, clock) necessary to describe Lpbam App1 are available.
To add more queues, click “Add Queue”
To delete an application (or a queue), right-click the application (or the queue) name and select “Delete”.
To rename an application (or a queue), right-click the application (or the queue) name and select “Rename”. Note that the application name is used in the generated project.
To switch between LPBAM applications, click the application name, this loads the LPBAM panel for the selected application.
To switch between queues in an LPBAM application, click the queue name: the middle and right panels are refreshed to display the selected queue and its configuration.
Figure 702. Adding an application
18.3 Describing an LPBAM application
18.3.1 Overview (SoC & IPs configuration, runtime scenario)
Describing an LPBAM application consists in configuring the SoC and IPs, as it is done for a standard STM32CubeMX project, as well as describing the runtime part of the application.
SoC and IPs configuration
To configure IP and SOC in the context of an LPBAM application, use the Pinout & Configuration and Clock configuration provided with the LPBAM application.
Figure 703. SoC and IPs configuration
With standard STM32CubeMX projects, the user must add the code to manage the runtime behavior of the main application based on STM32Cube HAL or LL driver APIs, such as HAL_COMP_Start, HAL_TIM_Start, HAL_TIM_Stop.
For LPBAM applications, STM32CubeMX provides the LPBAM Scenario & Configuration panel to create the runtime description (scenario). As shown in Figure 704, this panel is divided in three parts.
Figure 704. LPBAM scenario: creation and configuration panels
Note: LPBAM applications use the LPBAM firmware APIs and consist of chained DMA transfers.
In the context of an LPBAM application, the first panel is used for:
• Managing queues for the application.
• Browsing and adding nodes to the queue currently selected in STM32CubeMX user interface.
• Application specific settings. These settings cannot be changed nor disabled when using LPBAM on STM32U5 series.
The second panel displays the diagram of the queue currently selected for one selected queue of the LPBAM application.
The third panel lets the user to configure either the queue (if the queue name is clicked), or a node (if the node is selected on the diagram).
18.3.2 SoC& IPs: configuring the clock
The LPBAM subsystem is functional down to STOP2 mode and supports only IPs on the Smart run domain. Consequently, in the LPBAM context, only a subset of the clock tree can be configured. Refer to Section 4.10 for details on how to configure a clock tree in
STM32CubeMX.
18.3.3 SoC & IPs: configuring the IPs
Only IPs of the Smart run domain are available in the LPBAM context.
In the LPBAM context, most IPs show the same configuration possibilities as the main project. However, for some IPs, some additional configuration is needed. For example, when an IP internal interrupt can be used in the LPBAM context, a dedicated configuration Tab is shown.
Figure 706. Available IPs
Figure 707. IP configuration: advanced settings
All IPs used at runtime by the LPBAM must be configured in the Pinout & Configuration view. Their configuration must be coherent with the LPBAM scenario.
Clicking “Check LPBAM Design” on the upper right corner of the user interface returns, for each IP used but not configured in an LPBAM application, a warning in the output window.
Warning: “Check LPBAM Design” checks only that the IPs are configured in the “Pinout & Configuration”, it does not check whether the HAL configuration is coherent with the LPBAM APIs used in the scenario.
18.3.4 SoC & IPs: configuring low power settings
Starting with STM32CubeMX6.5, users can configure low power settings for their project. These settings (to be found under the PWR IP) are very important to minimize the power consumption of an LPBAM application.
18.3.5 LPBAM scenario: managing queues
An LPBAM scenario consists of one or more queues, each with one or more nodes. The center panel describes the scenario of the LPBAM application: click the queue name to display its diagram in the center panel and its configuration in the right panel. The name of the selected queue is underlined in blue.
To add more queues, click the “+” button in that panel, or click “Add queues” from the LPBAM management section in the left panel:
• The maximum number of queues is four on STM32U5 series, limited by the number of LPDMA1 channels.
• Adding an LPBAM application to the project automatically creates one empty queue for that application.
Warning: For LPBAM applications with multiple queues, STM32CubeMX does not manage the runtime synchronization between queues. It is the user’s responsibility when assembling its final application to “start” the different queues at runtime.
The “LPBAM Management” section allows to remove and rename queues:
• To delete a queue, right-click the queue name and select “Delete”.
• To rename a queue, right-click the queue name and select “Rename”.
• To switch between queues in an LPBAM application, click the queue name: the middle and right panels are refreshed to display the selected queue and its configuration.
18.3.6 Queue description: managing nodes
A queue description consists of a sequence of functional nodes on a timeline: the sequence is displayed as a diagram in the central panel and the queue configuration in the right panel.
To add nodes to a queue:
• Click the name of the queue to be updated.
• Use the “LPBAM function Toolbox”, in the left panel to browse the list of IPs and functions (LPBAM firmware APIs) that can be used to create nodes.
• Click the IP name to expand and see the list of available functions. • Click the “+” sign next to the function name to add the function as a node in the queue:
the queue diagram in the center panel is updated accordingly.
• Example: on Queue1 of LpbamAp1, COMP1 is started, then data transfer on COMP1 Output is performed (see Figure 709).
To remove nodes from the diagram, click the cross on the node right-end-upper corner.
Figure 709. Adding nodes to a queue
18.3.7 Queue description: configuring the queue in circular mode
STM32CubeMX offers the possibility to design circular queues:
• Select the queue to be configured by clicking the queue name in the center panel: the queue configuration is displayed in the right panel.
• Click the Circular mode checkbox to configure the queue in circular mode: by default, the queue loops back to the first node (see Figure 710).
• To loop back to a different node, click the end of the arrow and drag it to the node of choice.
• To remove the loop, uncheck Circular mode.
Some functions first configure the IP, then manage the data transfer. In case of circular mode, the loop can be plugged on the configuration (“Conf”) or on the data part (“Data”) of the function.
An example is provided in Figure 711: when the queue is executed, the two first nodes and the configuration of the third node are executed once. whereas the data transfer is repeated as part of the loop.
Figure 711. Queue looping back on IP data transfer
18.3.8 Queue description: configuring the DMA channel hosting the queue
The execution of an LPBAM queue consists of LPDMA chained transfers. The DMA hosting the queue execution must be configured as needed by the application (see Figure 712).
Figure 712. LPBAM queue: DMA configuration
Select the queue to be configured by clicking the queue name on the center panel, the configuration of the DMA channel hosting that queue is shown in the right panel.
Note that some settings usually available for configuring a DMA channel are not provided in the user interface, as they are directly managed either by STM32CubeMX or by the LPBAM driver.
DMA channel NVIC configuration
NVIC settings are available only if one DMA channel interrupt is enabled (see right panel in Figure 712). The preemption priority and sub priority ranges in the LPBAM context depend on the NVIC priority group set for the whole project (the main project with the LPBAM applications).
Warning: Always check preemption and sub-priorities in the LPBAM context after changing the NVIC priority group from the main project Pinout & Configuration view.
18.3.9 Node description: accessing contextual help and documentation
STM32CubeMX provides contextual help and link to reference documentation on LPBAM functions to guide the user during the function selection process:
• From the “LPBAM function Toolbox” in the left panel, hover the mouse on an IP name to show the contextual help with links to reference documentation (see Figure 713). • It is recommended to read carefully the LPBAM global documentation and the IP “Description, Usage and Constraint” to learn how to assemble nodes in a queue, several queues, what can be done and what cannot be done. Some restrictions apply and are due to the LPBAM mechanism. They are not coming from the IP itself or from HAL constraints.
18.3.10 Node description: configuring node parameters
Once a function is chosen from the “LPBAM Function Toolbox” and added to a queue, it can be configured. In the center panel, click on a node to select it: the function is highlighted in pink, and its configuration is shown in the right panel (see Figure 714).
The example shows the “Start” parameters of the LPBAM COMP1_Start function. The HAL driver uses the same parameter names to configure a COMP IP. As mentioned before, the LPBAM firmware is not a HAL driver. However, the IP being unique, the LPBAM driver has been designed so that the IP parameters use, whenever possible, the same naming as found in the HAL driver.
Warning: LPBAM IP functions access IP hardware resources, to be
properly configured in the “Pinout & Configuration” view.
When a parameter is set to a hardware resource such as a GPIO, the resource must be configured in the Pinout & Configuration view.
In the example shown in Figure 714, the COMP “Input Plus” is set to PC5. If PC5 is not configured in the “Pinout & configuration” view, the generated LPBAM application can gets a “null signal” on Input Plus, and will be not functional.
To fix this issue:
• Go to the Pinout&Configuration view
• Search PC5 using the search field
• Right-click the PC5 pin and select COMP_Inp (see Figure 715)
Figure 715. LPBAM node: configuring hardware resources
Another example can be made using a timer to generate a PWM signal. The HAL driver requires a timer channel to be configured as output. Same applies when using the LPBAM firmware.
Note: All constraints concerning the initial configuration of the IP are mentioned in the LPBAM firmware documentation. Use STM32CubeMX “LPBAM Design check” mechanism (see dedicated section) to detect missing configurations.
18.3.11 Node description: configuring a trigger
For all IPs and functions, with the LPBAM firmware it is possible to use a hardware signal to trigger a node. STM32CubeMX allows to configure such trigger from the node configuration panel. By default, the node execution is not triggered. When trigger is enabled, all possible trigger signals are listed.
Warning: It is the user responsibility to properly configure the triggers. STM32CubeMX does not check for configuration errors.
Taking the COMP function “Start” as an example (see Figure 716), choose the function execution to be triggered on the rising edge of hardware signal, for the example, then, select the hardware signal among the list of hardware signals proposed.
Figure 716. LPBAM node trigger configuration
If a node is a function managing LPTIM1_CH1, it is possible to select LPTIM1_CH1 as the trigger (see Figure 717).
Figure 717. LPBAM node triggered using timer channel
18.3.12 Node description: reconfiguring a DMA for data transfer
Nodes set to a function managing data transfers (all functions with associated data transfer and with a name not ending with _Config), come with a specific configuration section: “Reconfigure DMA for Data Transfer” (see Figure 718).
Each DMA data transfer is based on a specific configuration, including, among others, data size, buffer address, address increment. The DMA default settings are functional.
Figure 718. LPBAM node: reconfiguring a DMA
DMA settings can be changed, but they depend upon the IP and the function.
For example, for “COMP Output Level”: • Data transferred are output data and are transferred from the register IP to the memory. The “Source Address” referring to the IP data register is not incremented: STM32CubeMX user interface shows that the “Source address increment after transfer” parameter cannot be enabled. • Data transferred to memory can be saved at the same memory address, or in a Table:
in this case, the “Destination Address increment after transfer” can be disabled or left enabled (see Figure 718).
Figure 719. Reconfiguring DMA for data transfer when destination is memory
18.4 Checking the LPBAM design
STM32CubeMX offers users with the possibility to check their LPBAM design for coherency and completeness, by detecting:
• Incoherences between the IP LPBAM function selected for a node and the corresponding IP configuration.
• Wrong queue designs (the sequence of nodes is invalid).
Click CHECK LPBAM DESIGN to check all LPBAM applications currently available in the project. Results appear in the LPBAM output log window (see Figure 720).
Note: Messages raised on the LPBAM design do not prevent users to generate the C code for their project. Supported type of messages are ERROR (in red), Warning (in orange), and Information (in blue).
18.5 Generating a project with LPBAM applications
Click Generate Code from the main project view. As exemplified in Figure 720, the resulting project shows, in addition to the main project files and folders, the stm32_lpbam_conf.h file, a dedicated folder for the configuration code, and the utilities folder with the LPBAM utility firmware.
Figure 721. STM32CubeMX project generated with LPBAM applications
STM32CubeMX generates:
• In the Core/Inc folder, the stm32_lpbam_conf.h file that defines all the LPBAM modules enabled for the LPBAM applications, to be used by the LPBAM utility firmware.
• In the LPBAM folder, the code for the LPBAM applications and their scenarios. The lpbam_<application name>.h file provides the prototypes of the functions to call in the main project to initialize the application, build and initialize the scenario, link it with the DMA, start it, stop it, unlink it, and de-initialize it.
As an example, for the LpbamAp1 application, STM32CubeMX generates the following functions:
/* LpbamAp1 application initialization */ void MX_LpbamAp1_Init(void);
/* LpbamAp1 application - scenario initialization */ void MX_LpbamAp1_Scenario_Init(void);
/* LpbamAp1 application - scenario build */ void MX_LpbamAp1_Scenario_Build(void);
/* LpbamAp1 application - scenario link */ void MX_LpbamAp1_Scenario_Link(DMA_HandleTypeDef *hdma);
/* LpbamAp1 application - scenario start */ void MX_LpbamAp1_Scenario_Start(DMA_HandleTypeDef *hdma); /* LpbamAp1 application - scenario stop */ void MX_LpbamAp1_Scenario_Stop(DMA_HandleTypeDef *hdma);
/* LpbamAp1 application - scenario unlink */ void MX_LpbamAp1_Scenario_UnLink(DMA_HandleTypeDef *hdma);
/* LpbamAp1 application - scenario de-initialization */ void MX_LpbamAp1_Scenario_DeInit(void);
18.6 LPBAM application for TrustZone activated projects
Starting with STM32CubeMX 6.6.0, users can create LPBAM applications for projects with TrustZone activated.
1. Access to MCU selector and select an STM32U575/585 device
2. Click Create a new project
3. Choose the option “with TrustZone activated”
STM32CubeMX standard project view
STM32CubeMX standard project view proposes security settings for peripherals ( Figure 722) and the clock tree ( Figure 723).
STM32CubeMX LPBAM view
In STM32CubeMX LPBAM Application configuration context, the peripherals and the clock tree do not come with dedicated security settings (see Figure 724 and Figure 725). The choice of context, secure or nonsecure, is done at LPBAM application level ( Figure 726).
Security settings coherency check
1. Click
2. Enable Show Attribute Warning Messages to see details about LPBAM security related configuration issues (see Figure 727)
Figure 722. STM32CubeMX project - Peripheral secure context assignment
Figure 723. STM32CubeMX project - Clock source secure context assignment
Figure 724. LPBAM project - Peripheral no context assignment
Figure 726. LPBAM application - Secure context assignment
Appendix A STM32CubeMX pin assignment rules
The following pin assignment rules are implemented in STM32CubeMX:
• Rule 1: Block consistency
• Rule 2: Block inter-dependency
• Rule 3: One block = one peripheral mode
• Rule 4: Block remapping (only for STM32F10x)
• Rule 5: Function remapping
• Rule 6: Block shifting (only for STM32F10x)
• Rule 7: Setting or clearing a peripheral mode
• Rule 8: Mapping a function individually (if Keep Current Placement is unchecked)
• Rule 9: GPIO signals mapping
A.1 Block consistency
When setting a pin signal (provided there is no ambiguity about the corresponding peripheral mode), all the pins/signals required for this mode are mapped and pins are shown in green (otherwise the configured pin is shown in orange).
When clearing a pin signal, all the pins/signals required for this mode are unmapped simultaneously and the pins turn back to gray.
Example of block mapping with an STM32F107x MCU
If the user assigns I2C1_SMBA function to PB5, then STM32CubeMX configures pins and modes as follows:
• I2C1_SCL and I2C1_SDA signals are mapped to the PB6 and PB7 pins, respectively (see Figure 728).
• I2C1 peripheral mode is set to SMBus-Alert mode.
Figure 728. Block mapping
Example of block remapping with an STM32F107x MCU
If the user assigns GPIO_Output to PB6, STM32CubeMX automatically disables I2C1 SMBus-Alert peripheral mode from the peripheral tree view and updates the other I2C1 pins (PB5 and PB7) as follows:
• If they are unpinned, the pin configuration is reset (pin grayed out). • If they are pinned, the peripheral signal assigned to the pins is kept and the pins are highlighted in orange since they no longer match a peripheral mode (see Figure 729).
Figure 729. Block remapping
For STM32CubeMX to find an alternative solution for the I2C peripheral mode, the user will need to unpin I2C1 pins and select the I2C1 mode from the peripheral tree view (see Figure 730 and Figure 731).
Figure 730. Block remapping - Example 1
A.2 Block inter-dependency
On the Pinout view, the same signal can appear as an alternate function for multiple pins. However it can be mapped only once.
As a consequence, for STM32F1 MCUs, two blocks of pins cannot be selected simultaneously for the same peripheral mode: when a block/signal from a block is selected, the alternate blocks are cleared.
Example of block remapping of SPI in full-duplex master mode with an STM32F107x MCU
If SPI1 full-duplex master mode is selected from the tree view, by default the corresponding SPI signals are assigned to PB3, PB4 and PB5 pins (see Figure 732).
If the user assigns to PA6 the SPI1_MISO function currently assigned to PB4,
STM32CubeMX clears the PB4 pin from the SPI1_MISO function, as well as all the other pins configured for this block, and moves the corresponding SPI1 functions to the relevant pins in the same block as the PB4 pin (see Figure 733).
(by pressing CTRL and clicking PB4 to show PA6 alternate function in blue, then drag and drop the signal to pin PA6)
Figure 732. Block inter-dependency - SPI signals assigned to PB3/4/5
Figure 733. Block inter-dependency - SPI1_MISO function assigned to PA6
A.3 One block = one peripheral mode
When a block of pins is fully configured in the Pinout view (shown in green), the related peripheral mode is automatically set in the Peripherals tree.
Example of STM32F107x MCU
Assigning the I2C1_SMBA function to PB5 automatically configures I2C1 peripheral in SMBus-Alert mode (see Peripheral tree in Figure 734).
Figure 734. One block = one peripheral mode - I2C1_SMBA function assigned to PB5
A.4 Block remapping (STM32F10x only)
To configure a peripheral mode, STM32CubeMX selects a block of pins and assigns each mode signal to a pin in this block. In doing so, it looks for the first free block to which the mode can be mapped.
When setting a peripheral mode, if at least one pin in the default block is already used,
STM32CubeMX tries to find an alternate block. If none can be found, it either selects the
functions in a different sequence, or unchecks , and remaps all the blocks to find a solution.
Example
STM32CubeMX remaps USART3 hardware-flow-control mode to the (PD8-PD9-PD11PD12) block, because PB14 of USART3 default block is already allocated to the SPI2_MISO function (see Figure 735).
A.5 Function remapping
To configure a peripheral mode, STM32CubeMX assigns each signal of the mode to a pin. In doing so, it will look for the first free pin the signal can be mapped to.
Example using STM32F415x
When configuring USART3 for the Synchronous mode, STM32CubeMX discovered that the default PB10 pin for USART3_TX signal was already used by SPI. It thus remapped it to PD8 (see Figure 736).
A.6 Block shifting (only for STM32F10x and when
“Keep Current Signals placement” is unchecked)
If a block cannot be mapped and there are no free alternate solutions, STM32CubeMX tries to free the pins by remapping all the peripheral modes impacted by the shared pin.
Example
With the Keep current signal placement enabled, if USART3 synchronous mode is set first, the Asynchronous default block (PB10-PB11) is mapped and Ethernet becomes unavailable (shown in red) (see Figure 737).
Unchecking allows STM32CubeMX shifting blocks around and freeing a block for the Ethernet MII mode. (see Figure 738).
Figure 737. Block shifting not applied
Figure 738. Block shifting applied
A.7 Setting and clearing a peripheral mode
The Peripherals panel and the Pinout view are linked: when a peripheral mode is set or cleared, the corresponding pin functions are set or cleared.
A.8 Mapping a function individually
When STM32CubeMX needs a pin that has already been assigned manually to a function (no peripheral mode set), it can move this function to another pin, only if is unchecked and the function is not pinned (no pin icon).
A.9 GPIO signals mapping
I/O signals (GPIO_Input, GPIO_Output, GPIO_Analog) can be assigned to pins either manually through the Pinout view or automatically through the Pinout menu. Such pins can no longer be assigned automatically to another signal: STM32CubeMX signal automatic placement does not take into account this pin anymore since it does not shift I/O signals to other pins.
The pin can still be manually assigned to another signal or to a reset state.
Appendix B STM32CubeMX C code generation design
choices and limitations
B.1 STM32CubeMX generated C code and user sections
The C code generated by STM32CubeMX provides user sections as illustrated below. They allow user C code to be inserted and preserved at next C code generation.
User sections shall neither be moved nor renamed. Only the user sections defined by STM32CubeMX are preserved. User created sections will be ignored and lost at next C code generation.
** /* USER CODE BEGIN 0 */**
(..)
/* USER CODE END 0 */
Note: STM32CubeMX may generate C code in some user sections. It will be up to the user to clean the parts that may become obsolete in this section. For example, the while(1) loop in the main function is placed inside a user section as illustrated below:
/* Infinite loop */
** /* USER CODE BEGIN WHILE */ while (1)**
** {**
** /* USER CODE END WHILE */**
** /* USER CODE BEGIN 3 */**
** }**
/* USER CODE END 3 */
B.2 STM32CubeMX design choices for peripheral initialization
STM32CubeMX generates peripheral _Init functions that can be easily identified thanks to the MX_ prefix:
static void MX_GPIO_Init(void); static void MX_<Peripheral Instance Name>_Init(void); static void MX_I2S2_Init(void);
An MX_<peripheral instance name>_Ini t function exists for each peripheral instance selected by the user (e.g, MX_I2S2_Init). It performs the initialization of the relevant handle structure (e.g, &hi2s2 for I2S second instance) that is required for HAL driver initialization (e.g., HAL_I2S_Init) and the actual call to this function:
void MX_I2S2_Init(void)
{ hi2s2.Instance = SPI2; hi2s2.Init.Mode = I2S_MODE_MASTER_TX; hi2s2.Init.Standard = I2S_STANDARD_PHILLIPS; hi2s2.Init.DataFormat = I2S_DATAFORMAT_16B; hi2s2.Init.MCLKOutput = I2S_MCLKOUTPUT_DISABLE; hi2s2.Init.AudioFreq = I2S_AUDIOFREQ_192K; hi2s2.Init.CPOL = I2S_CPOL_LOW; hi2s2.Init.ClockSource = I2S_CLOCK_PLL; hi2s2.Init.FullDuplexMode = I2S_FULLDUPLEXMODE_ENABLE;
** HAL_I2S_Init(&hi2s2);**
}
By default, the peripheral initialization is done in main.c. If the peripheral is used by a middleware mode, the peripheral initialization can be done in the middleware corresponding
.c file.
Customized HAL_<Peripheral Name>_MspInit() functions are created in the stm32f4xx_hal_msp.c file to configure the low-level hardware (GPIO, CLOCK) for the selected peripherals.
B.3 STM32CubeMX design choices and limitations for
middleware initialization
B.3.1 Overview
STM32CubeMX does not support C user code insertion in Middleware stack native files although stacks such as LwIP might require it in some use cases.
STM32CubeMX generates middleware Init functions that can be easily identified thanks to the MX_ prefix:
MX_LWIP_Init(); // defined in lwip.h file
MX_USB_HOST_Init(); // defined in usb_host.h file
MX_FATFS_Init(); // defined in fatfs.h file
Note however the following exceptions:
• No Init function is generated for FreeRTOS unless the user chooses, from the Project Settings window, to generate Init functions as pairs of .c/.h files. Instead, a
StartDefaultTask function is defined in the main.c file and CMSIS-RTOS native function ( osKernelStart) is called in the main function.
• If FreeRTOS is enabled, the Init functions for the other middlewares in use are called from the StartDefaultTask function in the main.c file.
Example:
void StartDefaultTask(void const * argument)
{
/* init code for FATFS */
MX_FATFS_Init();
/* init code for LWIP */
MX_LWIP_Init();
** /* init code for USB_HOST */**
** MX_USB_HOST_Init();**
** /* USER CODE BEGIN 5 */ /* Infinite loop */ for(;;)**
** {**
** osDelay(1);**
** }**
** /* USER CODE END 5 */**
}
B.3.2 USB host
USB peripheral initialization is performed within the middleware initialization C code in the usbh_conf.c file, while USB stack initialization is done within the usb_host.c file.
When using the USB Host middleware, the user is responsible for implementing the USBH_UserProcess callback function in the generated usb_host.c file.
From STM32CubeMX user interface, the user can select to register one class or all classes if the application requires switching dynamically between classes.
B.3.3 USB device
USB peripheral initialization is performed within the middleware initialization C code in the usbd_conf.c file, while USB stack initialization is done within the usb_device. c file.
USB VID, PID and String standard descriptors are configured via STM32CubeMX user interface and available in the usbd_desc.c generated file. Other standard descriptors (configuration, interface) are hard-coded in the same file preventing support of USB composite devices.
When using the USB Device middleware, the user is responsible for implementing the functions in the usbd_<classname>_if.c class interface file for all device classes (such as usbd_storage_if.c).
USB MTP and CCID classes are not supported.
B.3.4 FatFs
FatFs is a generic FAT/exFAT file system solution well suited for small embedded systems.
FatFs configuration is available in ffconf.h generated file.
The initialization of the SDIO peripheral for the FatFs SD card mode and of the FMC peripheral for the FatFs External SDRAM and External SRAM modes are kept in the main.c file.
Some files need to be modified by the user to match user board specificities (BSP in STM32Cube embedded software package can be used as example):
• bsp_driver_sd.c/.h generated files when using FatFs SD card mode
• bsp_driver_sram.c/.h generated files when using FatFs External SRAM mode
• bsp_driver_sdram.c/.h generated files when using FatFs External SDRAM mode.
Multi-drive FatFs is supported, which means that multiple logical drives can be used by the application (External SDRAM, External SRAM, SD card, USB disk, User defined). However support of multiple instances of a given logical drive is not available (e.g. FatFs using two instances of USB hosts or several RAM disks).
NOR and NAND flash memory are not supported. In this case, the user shall select the FatFs user-defined mode and update the user_diskio.c driver file generated to implement the interface between the middleware and the selected peripheral.
B.3.5 FreeRTOS
FreeRTOS is a free real-time embedded operating system well suited for microcontrollers.
FreeRTOS configuration is available in FreeRTOSConfig.h generated file.
When FreeRTOS is enabled, all other selected middleware modes (e.g., LwIP, FatFs, USB) will be initialized within the same FreeRTOS thread in the main.c file.
When GENERATE_RUN_TIME_STATS, CHECK_FOR_STACK_OVERFLOW, USE_IDLE_HOOK, USE_TICK_HOOK and USE_MALLOC_FAILED_HOOK parameters
are activated, STM32CubeMX generates freertos.c file with empty functions that the user shall implement. This is highlighted by the tooltip (see Figure 739).
Figure 739. FreeRTOS HOOK functions to be completed by user
B.3.6 LwIP
LwIP is a small independent implementation of the TCP/IP protocol suite: its reduced RAM usage makes it suitable for use in embedded systems with tens of Kbytes of free RAM.
LwIP initialization function is defined in lwip.c, while LwIP configuration is available in lwipopts.h generated file.
STM32CubeMX supports LwIP over Ethernet only. The Ethernet peripheral initialization is done within the middleware initialization C code.
STM32CubeMX does not support user C code insertion in stack native files. However, some LwIP use cases require modifying stack native files (e.g., cc.h, mib2.c): user modifications shall be backed up since they will be lost at next STM32CubeMX generation.
Starting with LwIP release 1.5, STM32CubeMX LwIP supports IPv6 (see Figure 741).
DHCP must be disabled, to configure a static IP address.
Figure 740. LwIP 1.4.1 configuration
Figure 741. LwIP 1.5 configuration
STM32CubeMX generated C code reports compilation errors when specific parameters are enabled (disabled by default). The user must fix the issues with a stack patch (downloaded from Internet) or user C code. The following parameters generate an error:
• MEM_USE_POOLS: user C code to be added either in lwipopts.h or in cc.h (stack file).
• PPP_SUPPORT, PPPOE_SUPPORT: user C code required
• MEMP_SEPARATE_POOLS with MEMP_OVERFLOW_CHECK > 0: a stack patch required
• MEM_LIBC_MALLOC & RTOS enabled: stack patch required
• LWIP_EVENT_API: stack patch required
In STM32CubeMX, the user must enable FreeRTOS in order to use LwIP with the netconn and sockets APIs. These APIs require the use of threads and consequently of an operating system. Without FreeRTOS, only the LwIP event-driven raw API can be used.
B.3.7 Libjpeg
Libjpeg is a widely used C-library that allows reading and writing JPEG files. It is delivered within STM32CubeF7, STM32CubeH7, STM32CubeF2 and STM32CubeF4 embedded software packages.
STM32CubeMX generates the following files, whose content can be configured by the user through STM32CubeMX user interface:
• libjpeg.c/.h
The MX_LIBJPEG_Init() initialization function is generated within the libjpeg.c file. It is empty. It is up to the user to enter in the user sections the code and the calls to the libjpeg functions required for the application.
• jdata_conf.c
This file is generated only when FatFs is selected as data stream management type.
• jdata_conf.h
The content of this file is adjusted according to the datastream management type selected.
• jconfig.h
This file is generated by STM32CubeMX. but cannot be configured.
• jmorecfg.h
Figure 742. Libjpeg configuration window
Mbed TLS is a C-library that allows including cryptographic capabilities to embedded products. It handles Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols, that are used for establishing a secure, encrypted and authenticated link between two parties over an insecure network. Mbed TLS comes with an intuitive API and minimal coding footprint. Visit https://tls.mbed.org/ for more details.
Mbed TLS is delivered within STM32CubeF2, STM32CubeF4, STM32CubeF7 and STM32CubeH7 embedded software packages.
Mbed TLS can work without LwIP stack (see Figure 743).
If LwIP stack is used, FreeRTOS must be enabled as well (see Figure 744).
STM32CubeMX generates the following files, whose contents can be modified by the user through STM32CubeMX user interface (see Figure 745) and/or using user sections in the code itself:
• mbedtls_config.h
• mbedtls.h
• net_sockets.c (generated only if LwIP is enabled)
• mbedtls.c
Figure 744. Mbed TLS with LwIP and FreeRTOS
Figure 745. Mbed TLS configuration window
The STM32 TouchSensing library is a C-library that allows the creation of higher-end human interfaces by replacing conventional electromechanical switches by capacitive sensors with STM32 microcontrollers.
It requires the touch-sensing peripheral to be configured on the microcontroller.
STM32CubeMX generates the following files, whose contents can be modified by the user through STM32CubeMX user interface (see Figure 746, Figure 747, and Figure 748) and/or using user sections in the code itself:
• touchsensing.c/.h
• tsl_user.c/.h
• tsl_conf.h
Figure 746. Enabling the TouchSensing peripheral
Figure 747. Touch-sensing sensor selection panel
Figure 748. TouchSensing configuration panel
The PDM2PCM library is a C-library that allows converting a pulse density modulated (PDM) data output into a 16-bit pulse-code modulation (PCM) format. It requires the CRC peripheral to be enabled.
STM32CubeMX generates the following files, whose content can be modified by the user through STM32CubeMX user interface and/or using user sections in the code itself:
pdm2pcm.h/.c
B.3.11 STM32WPAN BLE/Thread (STM32WB series only)
STM32WPAN BLE and Thread middleware are now supported in STM32CubeMX.
Figure 749. BLE and Thread middleware support in STM32CubeMX
They are exclusive in a given project and configuration with FreeRTOS is not yet supported.
Application projects generated with STM32CubeMX can be found in the project folder of the STM32CubeWB MCU package.
Figure 750. STM32CubeWB Package download
This package can be installed through STM32CubeMX following the standard procedure described in Section 3.4.3: Installing STM32 MCU packages.
Figure 751. STM32CubeWB BLE applications folder
To enable BLE some peripherals (RTC, HSEM, RF) must be activated first.
Then, an application type must be selected, it can be one among Transparent mode, Server profile, Router profile or Client profile.
Finally, the mode and other parameters relevant to this application type must be configured.
Note: The BLE Transparent mode and all Thread applications require either the USART or the LPUART peripheral to be configured as well.
Thread configuration
To enable Thread some peripherals (RTC, HSEM, RF) must be activated first.
Then, an application type must be selected and the relevant parameters configured.
Figure 754. Thread application selection
B.3.12 CMSIS packs selection limitation
The restriction about applications comes from a simple generated code consideration: an application is meant to be the root of the execution (excluding the main function).
This means that the generated function defines the execution of the selected application. In that sense, it is meant to be the last call of the main method, and must not give hand back to the main function.Two applications cannot be called, as this means generating calls in the main function, and then the second call is never reached.
If you need to call both applications:
• An RTOS must run them in threads, or
• You manually add the right code to execute them (in that context, they are not applications, as they are not at the root of the execution), or
• Change the meaning of the application components.
B.3.13 OpenAmp and RESMGR_UTILITY
(STM32MPUs and STM32H7 dual-core products)
New software and hardware have been introduced on dual-core products to enable multi-core cooperation.
• For STM32MPUs only: the inter-processor communication controller (IPCC) used to exchange data between two processor instances relies on the fact that shared memory buffers are allocated in the MCU SRAM and that each processor owns specific register bank and interrupts.
• For STM32MPUs only: the OpenAMP middleware for intercommunication between Cortex-A and Cortex-M cores implements the RPMsg messaging protocol (see Figure 755). • The resource manager library (RESMGR_UTILITY) for system resource management:
multi-processor devices give the possibility to run independent firmware on several cores (see Figure 756). This implies a core could use some peripherals without knowledge of the usage of these same peripherals: the role of the resource management library is to control the assignment of a peripheral to a dedicated core and to provide a method to configure the system resources used to operate that peripheral (see Figure 757).
Figure 756. Enabling the Resource Manager for STM32MPUs
Figure 757. Resource Manager: peripheral assignment view
For more details visit STM32MPUs dedicated wiki site at https://wiki.st.com/stm32mpu.
Appendix C STM32 microcontrollers power consumption parameters
This section provides an overview on how to use STM32CubeMX Power Consumption Calculator.
Microcontroller power consumption depends on chip size, supply voltage, clock frequency and operating mode. Embedded applications can optimize STM32 MCU power consumption by reducing the clock frequency when fast processing is not required and choosing the optimal operating mode and voltage range to run from. A description of STM32 power modes and voltage range is provided below.
C.1 Power modes
STM32 MCUs support different power modes (refer to STM32 MCU datasheets for full details).
C.1.1 STM32L1 series
STM32L1 microcontrollers feature up to 6 power modes, including 5 low-power modes:
• Run mode
This mode offers the highest performance using HSE/HSI clock sources. The CPU runs up to 32 MHz and the voltage regulator is enabled.
• Sleep mode
This mode uses HSE or HSI as system clock sources. The voltage regulator is enabled and the CPU is stopped. All peripherals continue to operate and can wake up the CPU when an interrupt/event occurs.
• Low- power run mode
This mode uses the multispeed internal (MSI) RC oscillator set to the minimum clock frequency (131 kHz) and the internal regulator in low-power mode. The clock frequency and the number of enabled peripherals are limited.
• Low-power sleep mode
This mode is achieved by entering Sleep mode. The internal voltage regulator is in lowpower mode. The clock frequency and the number of enabled peripherals are limited. A typical example would be a timer running at 32 kHz.
When the wake-up is triggered by an event or an interrupt, the system returns to the Run mode with the regulator ON.
• Stop mode
This mode achieves the lowest power consumption while retaining RAM and register contents. Clocks are stopped. The real-time clock (RTC) an be backed up by using LSE/LSI at 32 kHz/37 kHz. The number of enabled peripherals is limited. The voltage regulator is in low-power mode.
The device can be woken up from Stop mode by any of the EXTI lines.
• Standby mode
This mode achieves the lowest power consumption. The internal voltage regulator is switched off so that the entire V CORE domain is powered off. Clocks are stopped and the real-time clock (RTC) can be preserved up by using LSE/LSI at 32 kHz/37 kHz.
STM32 microcontrollers power consumption parameters
RAM and register contents are lost except for the registers in the Standby circuitry. The number of enabled peripherals is even more limited than in Stop mode.
The device exits Standby mode upon reset, rising edge on one of the three WKUP pins, or if an RTC event occurs (if the RTC is ON).
Note: When exiting Stop or Standby modes to enter the Run mode, STM32L1 MCUs go through a
state where the MSI oscillator is used as clock source. This transition can have a significant impact on the global power consumption. For this reason, the Power Consumption Calculator introduces two transition steps: WU_FROM_STOP and WU_FROM_STANDBY . During these steps, the clock is automatically configured to MSI.
C.1.2 STM32F4 series
STM32F4 microcontrollers feature a total of 5 power modes, including 4 low-power modes:
• Run mode
This is the default mode at power-on or after a system reset. It offers the highest performance using HSE/HSI clock sources. The CPU can run at the maximum frequency depending on the selected power scale.
• Sleep mode
Only the CPU is stopped. All peripherals continue to operate and can wake up the CPU when an interrupt/even occurs. The clock source is the clock that was set before entering Sleep mode.
• Stop mode
This mode achieves a very low power consumption using the RC oscillator as clock source. All clocks in the 1.2 V domain are stopped as well as CPU and peripherals. PLL, HSI RC and HSE crystal oscillators are disabled. The content of registers and internal SRAM are kept.
The voltage regulator can be put either in normal Main regulator mode (MR) or in Lowpower regulator mode (LPR). Selecting the regulator in low-power regulator mode increases the wake-up time.
The flash memory can be put either in Stop mode to achieve a fast wake-up time. or in Deep power-down to obtain a lower consumption with a slow wake-up time.
The Stop mode features two sub-modes:
– Stop in Normal mode (default mode)
In this mode, the 1.2 V domain is preserved in nominal leakage mode and the minimum V12 voltage is 1.08 V.
– Stop in Under-drive mode
In this mode, the 1.2 V domain is preserved in reduced leakage mode and V12 voltage is less than 1.08 V. The regulator (in Main or Low-power mode) is in under-drive or low-voltage mode. The flash memory must be in Deep-power-down mode. The wake-up time is about 100 µs higher than in normal mode.
• Standby mode
This mode achieves very low power consumption with the RC oscillator as a clock source. The internal voltage regulator is switched off so that the entire 1.2 V domain is powered off: CPU and peripherals are stopped. The PLL, the HSI RC and the HSE crystal oscillators are disabled. SRAM and register contents are lost except for registers in the backup domain and the 4-byte backup SRAM when selected. Only RTC and LSE oscillator blocks are powered. The device exits Standby mode when an external reset (NRST pin), an IWDG reset, a rising edge on the WKUP pin, or an RTC alarm/ wake-up/tamper/time stamp event occurs.
• VBAT operation
It allows to significantly reduced power consumption compared to the Standby mode. This mode is available when the V BAT pin powering the Backup domain is connected to an optional standby voltage supplied by a battery or by another source. The V BAT domain is preserved (RTC registers, RTC backup register and backup SRAM) and RTC and LSE oscillator blocks powered. The main difference compared to the Standby mode is external interrupts and RTC alarm/events do not exit the device from V BAT operation. Increasing V DD to reach the minimum threshold does.
C.1.3 STM32L0 series
STM32L0 microcontrollers feature up to 8 power modes, including 7 low-power modes to achieve the best compromise between low-power consumption, short startup time and available wake-up sources:
• Run mode
This mode offers the highest performance using HSE/HSI clock sources. The CPU can run up to 32 MHz and the voltage regulator is enabled.
• Sleep mode
This mode uses HSE or HSI as system clock sources. The voltage regulator is enabled and only the CPU is stopped. All peripherals continue to operate and can wake up the CPU when an interrupt/event occurs.
• Low-power run mode
This mode uses the internal regulator in low-power mode and the multispeed internal (MSI) RC oscillator set to the minimum clock frequency (131 kHz). In Low-power run mode, the clock frequency and the number of enabled peripherals are both limited.
• Low-power sleep mode
This mode is achieved by entering Sleep mode with the internal voltage regulator in low-power mode. Both the clock frequency and the number of enabled peripherals are limited. Event or interrupt can revert the system to Run mode with regulator on.
• Stop mode with RTC
The Stop mode achieves the lowest power consumption with, while retaining the RAM, register contents and real time clock. The voltage regulator is in low-power mode. LSE or LSI is still running. All clocks in the V CORE domain are stopped, the PLL, MSI RC, HSE crystal and HSI RC oscillators are disabled.
Some peripherals featuring wake-up capability can enable the HSI RC during Stop mode to detect their wake-up condition. The device can be woken up from Stop mode by any of the EXTI line, in 3.5 µs, and the processor can serve the interrupt or resume the code.
• Stop mode without RTC
This mode is identical to “Stop mode with RTC “, except for the RTC clock which is stopped here.
• Standby mode with RTC
The Standby mode achieves the lowest power consumption with the real time clock running. The internal voltage regulator is switched off so that the entire V CORE domain STM32 microcontrollers power consumption parameters
is powered off. The PLL, MSI RC, HSE crystal and HSI RC oscillators are also switched off. The LSE or LSI is still running.
After entering Standby mode, the RAM and register contents are lost except for registers in the Standby circuitry (wake-up logic, IWDG, RTC, LSI, LSE crystal 32 kHz oscillator, RCC_CSR register).
The device exits Standby mode in 60 µs when an external reset (NRST pin), an IWDG reset, a rising edge on one of the three WKUP pins, RTC alarm (Alarm A or Alarm B), RTC tamper event, RTC timestamp event or RTC wake-up event occurs.
• Standby mode without RTC
This mode is identical to Standby mode with RTC, except that the RTC, LSE and LSI clocks are stopped.
The device exits Standby mode in 60 µs when an external reset (NRST pin) or a rising edge on one of the three WKUP pin occurs.
Note: The RTC, the IWDG, and the corresponding clock sources are not stopped automatically by entering Stop or Standby mode. The LCD is not stopped automatically by entering Stop mode.
C.2 Power consumption ranges
STM32 MCUs power consumption can be further optimized thanks to the dynamic voltage scaling feature: the main internal regulator output voltage V12 that supplies the logic (CPU, digital peripherals, SRAM and flash memory) can be adjusted by software by selecting a power range (STM32L1 and STM32L0) or power scale (STM32 F4).
Power consumption range definitions are provided below (refer to STM32 MCU datasheets for full details).
C.2.1 STM32L1 series features three VCORE ranges
• High performance Range 1 (V DD range limited to 2.0-3.6 V), with the CPU running at up to 32 MHz
The voltage regulator outputs a 1.8 V voltage (typical) as long as the V DD input voltage is above 2.0 V. Flash program and erase operations can be performed.
• Medium performance Range 2 (full V DD range), with a maximum CPU frequency of
16 MHz
At 1.5 V, the flash memory is still functional but with medium read access time. Program and erase operations are still possible.
• Low performance Range 3 (full V DD range), with a maximum CPU frequency limited to
4 MHz (generated only with the multispeed internal RC oscillator clock source)
At 1.2 V, the flash memory is still functional but with slow read access time. Program and erase operations are no longer available.
C.2.2 STM32F4 series features several VCORE scales
The scale can be modified only when the PLL is OFF and when HSI or HSE is selected as system clock source.
• Scale 1 (V12 voltage range limited to 1.26 - 1.40 V), default mode at reset.
HCLK frequency range = 144 MHz to 168 MHz (180 MHz with over-drive).
This is the default mode at reset.
• Scale 2 (V12 voltage range limited to 1.20 - 1.32 V).
HCLK frequency range is up to 144 MHz (168 MHz with over-drive).
• Scale 3 (V12 voltage range limited to 1.08 - 1.20 V), default mode when exiting Stop mode.
HCLK frequency ≤120 MHz.
The voltage scaling is adjusted to f HCLK frequency as follows:
• STM32F429x/39x MCUs:
– Scale 1: up to 168 MHz (up to 180 MHz with over-drive) – Scale 2: from 120 to 144 MHz (up to 168 MHz with over-drive) – Scale 3: up to 120 MHz.
• STM32F401x MCUs:
No Scale 1
– Scale 2: from 60 to 84 MHz – Scale 3: up to 60 MHz.
• STM32F40x/41x MCUs:
– Scale 1: up to 168 MHz
– Scale 2: up to 144 MHz
C.2.3 STM32L0 series features three VCORE ranges
• Range 1 (V DD range limited to 1.71 to 3.6 V), with CPU running at a frequency up to