STM32CubeMX
18 Creating LPBAM projects ¶
• add/remove LPBAM applications
• for each LPBAM application, create queues
• for each queue, create functional nodes using the LPBAM firmware API available for peripherals on the Smart Run Domain
• for each LPBAM application, configure the pinout, the clock tree, and HAL-related configurations for the peripherals on the Smart Run Domain.
For details on how to work with this view, refer to Section 18: Creating LPBAM projects.
Figure 224. LPBAM window
4.17 CAD Resources view
STM32CubeMX CAD Resources view allows the user to quickly access and download schematic symbols, PCB footprints and 3D CAD models for one or more design toolchains. It requires STM32CubeMX to be connected to the Internet.
To configure and check the Internet connection select Help > Updater settings to open STM32CubeMX updater settings window.
CAD Resources can be accessed from the MCU Selector window and from STM32CubeMX project view.
Access from MCU selector
• Open the MCU selector from STM32CubeMX homepage
• Select an MCU commercial part number (Marketing status must not be “Coming soon”)
• Select the CAD Resources tab to see the CAD resources (see Figure 225). - Use the slider to go down the panel and access the different resource views (Symbols, Footprint, and 3D models).
Note: For MCU commercial part numbers in “Coming Soon” Marketing status, there are no CAD resources available (see Figure 226).
To select the resources for download (see Figure 227)
• Select the design toolchain
• Select the CAD formats
• Accept terms and conditions
• Click to download
• Specify the download location
Figure 227. CAD Resources selection for download
Access from STM32CubeMX project view
• Open an STM32CubeMX project (the MCU must not be in “Coming Soon” Marketing status)
• Select the CAD tab from the Tools panel to access CAD Resources (see Figure 228).
Figure 228. CAD Resources in Tools panel
The Symbol view reflects the STM32CubeMX project pinout configuration and, optionally, the labeling (see Figure 229). The downloaded CAD files are aligned with the pinout configuration and optionally, with the labels as well.
Figure 229. CAD Resources for STM32CubeMX project
4.18 Boot path
STM32CubeMX introduces the possibility to configure the boot path for the STM32H5 series.
Note: STM32H56x and STM32H503 do not support cryptographic hardware accelerator (a feature needed for the ST-iROT and ST-uROT), therefore the full spectrum of boot paths is not available for these MCUs.
For details about boot path and its usage, read the wiki page available on www.st.com, and the guide located under the Utilities folder of the STM32Cube firmware package.
This section details, through examples, how to configure a boot path and generate the associated code. It includes compilation, encryption, and provisioning.
4.18.1 Available boot paths
The following tables give an overview of the different boot paths supported by STM32CubeMX, depending upon the device.
Table 21. Boot paths without TrustZone (TZEN = 0)
MCU
Application
OEM-iRoT
→ Application
OEM-iRoT→ uRoT
→ Application
ST-iRoT → Application
ST-iRoT → uRoT
→ Application
STM32H503x
√
√
Table 22. Boot paths with TrustZone (TZEN = 1) (1)
MCU
** S/NS application**
OEM-iRoT → S/NS application, and OEMiRoT → S/NS application (assembled)
ST-iRoT → S application
ST-iRoT → uRoT S/NS application, and ST-iRoT→ S/NS application
STM32H56x
√
√
STM32H57x
√
√
√
√
STM32H54
√
1. S: secure, NS: nonsecure.
Table 23. Boot paths for STM32H7RS devices (1)
MCU
Application
OEM-iRoT → application
ST-iRoT → application
ST-iRoT → OEM-uRoT → application
STM32H7RSx
√
√
√
√
1. S: secure, NS: nonsecure.
The following figures indicate the boot paths that STM32CubeMX can configure, and the entry points after reset.
The related user option bytes are configured automatically (through Trusted Package
Creator installed with STM32CubeMX), and programmed during the provisioning stage.
Figure 231. Boot paths for STM32H57x devices
Figure 232. Bootpath scheme for STM32H5_4M devices
Figure 235. Application boot path (OEM-iRoT)
Figure 237. Application boot path: ST-iRoT and uRoT secure/nonsecure project
Figure 238. Application boot path:
ST-iRoT and secure/nonsecure user application assembled
Figure 240. Application boot path:
(OEM-iRoT and secure/nonsecure user application assembled)
4.18.2 Creating a boot path project: an example
Prerequisites
• Hardware: Discovery board STM32H573I-DK-REVC
• Tools
– STM32CubeMX-6.8.0 or later
– Trusted Package Creator (embedded in STM32CubeMX installation folder)
– CubeFW must be installed through STM32CubeMX
– IAR Embedded Workbench ® rev 9.20.4 or later
4.18.3 How to configure an OEM-iRoT boot path
The following instructions describe how to generate an OEM immutable Root of Trust (OEM-iRoT) boot path. The procedure to generate other boot paths is similar, but the data required for the configuration can be different.
Step 1: Selecting the MCU
Figure 243. Peripheral initialization
If you click yes, there will be an error during the secure code compilation. By default, all peripherals are set as secure, and the memory allocation for the secure code (defined through the OEM-iRoT_boot application) is too small. Step 2: Project creation with OEM-iRoT boot path
For this example, enable TrustZone (TZEN = 1).
Figure 244. Boot paths for STM32H56x devices
Select the option “with TrustZone activated ?” on the popup window, as shown below.
Figure 245. Activate TrustZone
Step 3: Device and peripherals configuration
The device and its peripherals can be configured. In this example, the default configuration is kept.
Figure 246. Device and peripherals configuration
Step 4: Overall configuration
Configure the application ( Figure 247), then save the project ( Figure 248).
Figure 247. Configuring the project
Step 5: Boot path selection
The possible first stages are proposed according to selected device and project structure.
Figure 249. Boot path selection
• Select OEM-iRoT for this example
Figure 250. Select OEM-iRoT
Figure 251. First boot path stage
• All possible boot paths for the second stage are proposed according to the selected device and project structure.
• Select “Secure Application ”, it generates secure and nonsecure codes.
Figure 252. Select Secure Application
• Click on FINISH to generate the binary, RoT_Provisioning folder, and sub-folders.
Figure 253. Last boot path stage
Note: If a selected boot path is not supported, a warning message is displayed, and the “FINISH” button is grayed out.
Note: For STM32H56x and STM32H523x devices it is not possible to configure the OEM-iRoT boot path if the flash size of the current MCU is not aligned with the FLASH_SIZE entry in the map.properties file. A pop-up window (see Figure 255) is displayed.
Step 6: Authentication and encryption keys regeneration, option byte file generation
Customization of OEM-iROT configuration file (OEMiROT_Config.obk):
• The default configuration file of CubeFW can be used, but the default keys must be regenerated or replaced
• To customize the configuration file, proceed as follow:
a) Launch Trusted Package Creator and select STM32H5 (click edit in Project
Manager as indicated in Figure 254)
b) Open OBkey tab
c) The default keys can be regenerated
d) The OEMiROT_Config.obk file is generated. The modified parameters are saved in OEMiROT_Config
Figure 257. Authentication and encryption keys regeneration
• The H5-Image Gen1 and Gen2 tabs indicate the location of the image configuration files and the path of the binary input and output files. Keep the default settings.
Figure 258. Secure image configuration
Figure 259. Nonsecure image configuration
Figure 260. Generate the code
Figure 261. Code is generated
Additional directories, including the IDE environment, are created.
Figure 262. Secure and nonsecure IDE directories
The S and NS applications can be developed using the generated code skeletons.
Step 8: Code compilation
Select Project → Option → Build Actions. The links to the Trusted Package executable, and to the secure and nonsecure application xml files are filled automatically.
Figure 263. IDE post build commands
The secure code must be generated before the nonsecure one. Compile each code separately (right click on Project → Rebuild all). The secure and nonsecure signed and encrypted binaries are generated during the post build phase.
Figure 264. Trusted Package Creator output directory
The program cannot be flashed using an IDE. Use provisioning scripts found in the user environment, and double click on the provisioning.bat file ( Figure 265). During provisioning, log files are generated to inform the user about the activity. Follow the on-screen instructions ( Figure 266).
In the user environment, STM32CubeMX has generated an env.bat file, containing the information required for provisioning. Do not change this file.
A pop-up (see Figure 267) appears if you forget to compile the project OEMiRoT_Boot in the CubeFW.
4.18.4 How to configure an ST-iRoT boot path
The configuration for an ST immutable Root of Trust (ST-iRoT) boot path. The requirements are the same of the previous example. Step 1: Generating the code
• Select an STM32H57x MCU
• Create a project with TrustZone activated (TZEN = 1)
• In Project Manager, choose “Secure Project”
• Save the project
• Go to “Boot Path and Debug Authentication” tab, and press the Select button
• Choose ST immutable Root of Trust (ST-iRoT)
Figure 268. Select ST-iRoT
• Select Secure Application
• Click “FINISH”, the boot path configuration panel is displayed (see Figure 270), use it to configure the application, then press the GENERATE CODE button to generate the code for the selected toolchain
Figure 270. Boot path and Debug Authentication tab
For this boot path, only the secure project is generated.
Figure 272. Code is generated
Additional directories, including the IDE environment are created.
Figure 273. Secure project completed
Secure applications can be developed using the generated code skeletons.
The Post build command creates a secure compiled encrypted code for the provisioning.
Step 2: Code compilation
The generated binaries are automatically encrypted
• Open the project in the selected toolchain, for example IAR
– Select: Project → Option → Build Actions
– The links to the Trusted Package executable and to the secure application xml are filled automatically
– Compile secure (right click on Project → Rebuild all)
Figure 274. IDE post build commands
ST-iRoT board provisioning
The program cannot be flashed using an IDE, use the provisioning scripts found in the user environment.
• Double click on the provisioning.bat file ( Figure 275)
Figure 275. Board provisioning
• During provisioning, log files are generated to inform the user about the activity
• Follow the on-screen instructions ( Figure 276)
Figure 276. On-screen instructions
In the user environment STM32CubeMX has generated an env.bat file containing the required data for provisioning, do not change it.
Figure 277. Environment configuration file
4.18.5 How to configure an assembled boot path
The configuration described below is an example of an assembled boot path.
Prerequisites:
• Hardware: Discovery board STM32H573I-DK-REVC or later
• Required tools
– Secure manager package, to be downloaded and installed from www.st.com – STM32CubeMX-6.9.0 or later
– STM32 Trusted Package Creator (embedded in STM32CubeMX installation
folder)
– IAR Embedded Workbench rev 9.20.4 or later, and the patch in the
STM32CubeH5 firmware (Version 1.1.0 or later), named EWARM/EWARMv8_STM32H5xx_Vx.x.x.zip.
Step 1: Configure flash_layout.h file
• Go to STM32Cube\Repository\STM32Cube_FW_H5_VX.X.X\Projects\ STM32H573I-DK\Applications\ROT\OEMiROT_Boot\Inc
• Open flash_layout.h
• Set the value of this define to 1 to assemble the secure and nonsecure binaries into one: #define MCUBOOT_APP_IMAGE_NUMBER 1.
Figure 278. The flash_layout.h file
Step 2: Compile OEMiROT_Boot project - Open OEMiROT_Boot with your preferred tool chain, and recompile the project.
– The map.properties file is automatically updated
(CODE_IMAGE_ASSEMBLY=0x01)
– The image file (OEMiRoT_NS_Code_Image.xml) is automatically updated (firmware area size)
Step 3: OEMiROT (assembled) code generation
• Open STM32CubeMX application and create a new project with the H5 series
(example: choose “STM32H573ZITxQ”)
• Go to Project Manager window, and select secure and nonsecure application
• Add a name for the project and save it
• Go to Boot Path and Debug Authentication Panel: in Boot path selection, click on Select button
• Select OEM-iRoT in the boot path wizard window, and click Next
• Select Secure application, and click Finish
Figure 279. The map.properties file
• Generate and build the project
• Open the project folder. A Python script assembles both binaries (Secure, Non Secure), then the TPC signs them:
– Assembled_OEMiRot_Boot_Path_Example_assembled.bin → File assembled by the Python script
– Assembled_OEMiRot_Boot_Path_Example_enc_sign.hex → File signed by the TPC
Figure 283. Project folder
• The post build command is added only for the Non Secure project.
4.18.6 How to configure OEM-uRoT (STiRot uROT) boot path
• Select an STM32H57x MCU
• Create a project with TrustZone activated (TZEN = 1), see Figure 284
• In Project Manager, save the project, see Figure 285 • Go to “Boot Path and Debug Authentication” tab, and press the Select button, see Figure 286
• Select “ST immutable Root of Trust (ST-iRot)”, then click “NEXT”, see Figure 287
• Select “OEM updatable Root of Trust (OEM-uRoT)”, then click “NEXT”, see Figure 287
• Select “Secure Application”, then click “FINISH”, see Figure 288 • The panel of boot path configuration is displayed, use it to configure the boot path in the “Boot Path and Debug Authentication” tab, see Figure 289
• Generate and build the project, see Figure 292 and Figure 293
Figure 286. Boot path and debug authentication panel
4.18.7 How to configure ST-iRoT boot path with STM32H7RS devices
Go through the following steps:
1. Select an STM32H7S3Vx MCU ( Figure 294)
2. A popup (see Figure 295) asks to preconfigure the Memory Protection Unit. It is recommended to optimize the speculative read access of the core. Select “Yes” to keep the default configuration.
3. In Project Manager Window, check only “Appli Project”, name the project, and save it ( Figure 296).
|
|
|
Go to “Boot Path and Debug Authentication” tab and press the Select button ( Figure 297). 5. Select “ST immutable Root of Trust (ST-iRoT)”, then click “NEXT” ( Figure 298).
6. Select “Application”, then click “FINISH” ( Figure 299).
7. The panel of boot path configuration is displayed (see Figure 300), use it to configure the boot path in the “Boot Path and Debug Authentication” tab.
Figure 298. First boot path stage |image275|
Figure 300. Boot path and debug authentication panel
Note: For STM32H5 devices with a 4-Mbyte flash size, the Boot Path feature is only supported in TrustZone-enabled projects. Its configuration is no longer performed in the STM32CubeMX user interface.
In the STM32CubeMX user interface, links are provided to wiki pages for each supported Boot Path type. These pages guide the user on how to configure the Boot Path both before and during the provisioning stage.
Figure 303. The supported Boot Path in STM32H5 with 4-Mbyte devices
4.19 HSP middleware “HSP_Engine”
4.19.1 Outline of HSP
The hardware signal processor (HSP) is an on-chip hardware accelerator that is used to compute intensive signal-processing tasks instead of the CPU.
Using the HSP improves real-time performance and reduces CPU load. It is intended for:
• Running real-time control loops
• Performing metering and measurement calculations
• Processing small convolutional neural networks
• Handling general signal-processing tasks
The main component of the HSP is a high-performance signal processor engine (SPE). It supports computations in both 32 bit floating-point and 8 bit integer formats, and is responsible for running the HSP microcode, or firmware.
4.19.2 STM32CubeMX implementation for HSP
STM32CubeMX enables the configuration of:
• The HSP features - including middleware parameters and modes
• Peripheral settings
• Clock tree
• GPIO pins.
It automatically generates the code required to run applications that make use of the HSP.
The implementation of this feature is divided into two parts at STM32CubeMX level:
• HSP peripheral [HSP1]
• HSP Middleware [HSP_ENGINE]
HSP peripheral [HSP1]
The HSP configuration screen is illustrated in the following figure.
Figure 304. HSP1 Modes and configuration in STM32CubeMX
HSP1 supports the following two modes:
– The Activation mode without parameters
– The Debug mode
The activation of these modes is illustrated in Figure 305: Activating the debug mode for the HSP1 peripheral.
Figure 305. Activating the debug mode for the HSP1 peripheral
The interruptions are managed in the IP, through the NVIC settings tab as illustrated in the figure below.
Figure 306. NVIC interrupt table for the HSP1 peripheral
– HAL drivers are copied into the project directory.
– Once HSP1 IP is enabled the corresponding HSP_Engine middleware is enabled automatically.
– MX_HSP_Engine_Init method is called in main.c and its implementation is in hsp_engine.c.
HSP Middleware [HSP_ENGINE]
• The HSP_ENGINE is used by the application to run one of the following tasks:
– DSP
– CNN
– direct
– processing list.
• It supports two modes:
– Accelerator mode
– Sequencer mode
Accelerator mode
– The Accelerator mode allows users to configure parameters listed under the general tab once the “Accelerator” option is checked in the mode.
– The configurations by STM32CubeMX are illustrated in the screenshot listed below.
The following figures illustrate the activation of HSP_Engine in Accelerator mode:
Figure 307. Activating the HSP in Accelerator mode
Figure 308. Parameters to be configured for HSP feature in the Accelerator mode
The following figures illustrated the configuration of HSP_Engine in Accelerator mode:
Figure 310. Parameters to be configured for HSP feature in the Accelerator mode
Figure 312. Clock configuration view for HSP in Accelerator mode
The following figures illustrate the steps before code generation:
Figure 313. Code generation for HSP in Accelerator mode
Figure 314. Files copied from firmware while generating the code
Sequencer mode
The Sequencer mode is implemented in STM32CubeMX UI via tabs under the configuration section as described below.
• General tab
The “General tab” contains:
– General settings of the middleware.
– Settings of the modules to be integrated.
– Clock settings.
The parameters in this tab may relate either to the Sequencer or to the Accelerator mode. The tab is illustrated in the figure below.
Figure 316. General tab
• Processing List tab
The Processing List tab is illustrated in the figure below.
Figure 317. The processing list tab
A portion of the microcode (firmware) is stored in a dedicated private ROM and provides optimized signal processing routines, referred to as processing functions.
The HSP is capable of executing ordered sequences of these operations, called processing lists.
A given processing list is characterized by its name:
– The processing list name must be unique since it distinguishes one processing list from another.
– The UseEvent parameter is represented as a checkbox. When this checkbox is selected, an additional GUI section appears, allowing the configuration of the associated event such as source, type, synchronization, and so on.
Figure 318. A processing list associated with an event
Actions that can be performed on a processing list:
– Add list: Creates a new list.
– Add function: Insertse functions into the created lists.
– Delete: Clears the whole processing list.
– Show snippet code: Displays the appearance of the generated code.
Figure 319. Snippet code action
– The elements of a processing list are functions.
– A given function is characterized by:
A function.
An argument which is a list that changes depending on the chosen function.
Figure 320. Function category
• Buffers tab
The buffer tab groups the following items:
– The argument parameter depends on other HSP GUI elements, which are buffers found under the Buffers tab.
– BRAM provides the memory space that holds the data used by the processing list and the created buffers.
– The processing list uses buffers to read/write data from/to BRAM.
This is illustrated in the figure below.
Figure 321. Buffers tab
• State Buffers tab
A state buffer is used whenever an algorithm needs to preserve internal information between successive processing calls.
The UI allows the declaration of state buffer resources in HSP BRAM memory space. These kinds of resources are required for “FIR & IIR” processing functions used by the processing list.
Figure 322. State buffers tab
• Events tab
The processing list tab is linked with another tab which is the events one.
The events tab lists the used events that are generated during the execution of that list and how they are handled.
Note: A used event is an event associated with a processing list through the combo box ID, with the box “UseEvent” checked.
Only events with ID in the range [1, 22] can be used and configured, Event IDs outside this range can be associated to a processing list but cannot be used or configured since the checkbox “UseEvent” is unchecked and grayed out.
The Event tab is a read only tab. It displays only the events linked to the processing list.
Figure 323. A processing list linked with an event
Figure 324. Events tab
• Output Triggers tabs
The output trigger is a signal generated by the HSP (or by the processing list logic) to indicate that a specific event related to the processing list has occurred. This is illustrated in the figure below.
Figure 325. Output Triggers tab
When the Trigger Output is enabled and the source for a given trigger is selected from the dropdown list, the corresponding code is automatically appended to the end of the hsp_engine.c file in the generated project.
** /* Configure the Trigger Output */ if (HSP_CORE_OUTPUT_SetConfig(&hmw, HSP_CORE_TRGO_0, HSP_CORE_TRGO_SRC_STREAM) != HSP_CORE_OK)**
** {**
** Error_Handler();**
** } if (HSP_CORE_OUTPUT_Enable(&hmw) != HSP_CORE_OK)**
** { **
** Error_Handler();}**
• The code generation
For Accelerator mode:
The section below lists the generated code for an STM32CubeMX project that configures HSP_ENGINE middleware in Accelerator mode.
Figure 326. Generated Project tree for HSP configured in Accelerator mode
a-1) Under HSP_Engine/App folder:
The app_hsp_bram_alloc.c file contains the instructions for memory allocation of
BRAM
The app_hsp_engine_process.c file contains the declaration and initialization of the middleware, located in the App folder for the HSP_Engine. a-2) Under HSP_Engine/Target folder:
The hsp_engine.c implements the function that initializes the low-level portion of the driver, HSP_Engine_IF_Init(). It also implements the functions that enable and disable the peripheral clock, HAL_HSP_MspInit() and HAL_HSP_MspDeInit().
For Sequencer mode:
The section below lists the generated code for an STM32CubeMX project that configures HSP_ENGINE middleware to treat two processing lists:
– ProcessingListExample1
– ProcessingListExample2
The project tree for the HSP configured in Sequencer mode:
Figure 327. Generated Project tree for HSP configured in sequencer mode
In the main.c file located in the User/core directory, the MX_HSP_Engine_Init() and MX_HSP_Engine_Process() functions are called. Generated files for HSP configured in Sequencer mode: b-1) Under HSP_Engine/App folder:
The app_hsp_bram_alloc.c file: generated file to implement all memory allocation in BRAM
The app_hsp_engine_process.c file: generated template file that allows the user to implement his own process functions for example Run Direct, DSP, CNN commands Run Processing with CDEG or CSEG interfaces app_hsp_engine_seq.c file:
This file contains the definitions of the functions listed below (the logic for the record and configuration of Processing lists):
– MX_HSP_SEQ_Record_PL_ProcessingListExample1()
– MX_HSP_SEQ_Record_PL_ProcessingListExample2()
The hsp_engine.c contains instructions to perform the following steps:
1) Enabling HSP event generation
2) Allocating BRAM resources
3) Handling the processing list (calling the recording PL functions)
4) Configuring the trigger output
Note: For the both Accelerator and Sequencer modes, the content for files under Drivers and Middlewares folder are copied from the firmware into the project tree.
4.20 PLAY feature presentation
4.20.1 Introduction
The PLAY IP is a programmable logic array integrated into STM32 devices to allow users to create custom logic and state machines directly within the MCU, without the need for external programmable logic devices like FPGAs. This document describes how to manage and configure the PLAY IP in STM32CubeMX, specifically for the STM32H5 4M series.
4.20.2 Peripheral overview
PLAY is a flexible logic array composed of programmable logic elements (look-up tables, LUTs) with four inputs and one output each. It supports complex logic functions by cascading these elements. Inputs and outputs can be selected from external GPIOs, internal peripheral signals, or software registers.
Figure 328. PLAY feature in STM32CubeMX
Activation and mode selection
Activate the PLAY feature by selecting the checkbox located in the Mode tab of the user interface.
When the “Activated” option is selected, two groups of parameters (two main modes) are accessible in the Mode section:
• Inputs activated: A list of 16 check-boxes, each representing a GPIO signal required for the operation of the PLAY IP, is named PLAY_IN. - Outputs activated: A list of 16 check-boxes, each representing a GPIO signal generated by the PLAY IP, is named PLAY_OUT.
Each group corresponds to a tab in the Configuration part:
• Input MUX settings: 16 independent multiplexers each dedicated for configuring a specific input. - Output MUX settings: 16 independent multiplexers each dedicated for configuring a specific output.
Figure 329. Activating the PLAY feature
4.20.3 Key features
16 inputs
Sixteen inputs are selectable from a maximum of 128 signals. The system implements 16 independent multiplexers (MUXs), each supporting eight input signals. One input per MUX is sourced from a GPIO signal, which must be activated at the beginning.
• The 128 signals include 16 external GPIOs and internal signals from peripherals such as TIM, SAI, MDF, or clocks such as LSE, HSI.
Figure 330. Input Signals
For each selected input, the user can perform the following actions:
• Change the signal names to simplify the configuration. By default, the system uses the name of the signal.
• Set the minimum pulse width. Configure the filtering mode by specifying the minimum pulse width. The mode can be set to bypass (default) or to a value from 1 to 255. • Set the edge detection by defining the kind of edge transition (rising, falling or both). The Bypass option is used to disable the mode which is the default option.
Start by selecting the source for MUX n. After a signal is chosen, the system automatically displays options for the user name, minimum pulse width, and edge detection settings.
Figure 331. Input settings to be filled by the user
16 Outputs
Sixteen discrete MUX units are implemented. Each MUX acts as a 32-to-1 selector, providing access to a pool of 16 immediate LUT outputs and 16 clock-stabilized registered outputs.
An output can be direct or registered with clock-enable options.
Figure 332. Setting the Output Source for the MUX0 from the list of outputs
Figure 333. Output settings
Feedback of registered outputs to inputs enables finite state machine creation.
Logic elements
Configure the logic elements by using the “Look Up Table Settings” tab in the STM32CubeMX user interface.
• The “Look Up Table Settings” tab contains 16 groups of settings.
• Each group of settings is named LookUp Table X (where X can be a value from 0 to 15) and has the following parameters:
– Input0
– Input1
– Input2
– Input3
– LUT truth table
– Clock gate
Figure 334. Entries for the Look Up table
Input X:
Once an input X is enabled, the following parameters are added to the GUI:
– Signal Type X – Signal Name X
• Signal Type X:
A drop down list used to select the input category.
The available categories are:
– Output of IN MUX
– SW Trigger
– LUT direct output signal – LUT registered output signal
• Signal Name X:
A dependent field where the content is determined by the value selected in Signal Type X.
After a type is chosen, this field presents the list of all valid signals for that category and allows the user to select one of them (The list depends of Input Category).
For Output Registered Signals a warning should be displayed if the corresponding Clock Enable Parameter is Off.
For Input Signals, the list of User Names should be displayed and grayed out if not enabled from I/Os Activated Mode or if the peripheral is deactivated.
By default, the value is set to SWIN 15.
LUT Truth table
Figure 335. LUT truth table parameter
The LUT truth table consists of two elements:
• Field 1: A field that displays the result of the calculation performed on the input, depending on the output required by the user in the “OUT column”.
• Field 2: A grid icon that, when selected, opens the visual representation of the LUT truth table.
This is a dynamic visual representation. If the user enables any input, the system adds rows and populates them with the already configured input.
To obtain the result, which is a compact representation of how OUT behaves for all possible input combinations, the user must select the “OK” button.’
Figure 336. LUT Calculation table
Clock gate:
A graphical user interface parameter that indicates whether the clock toggles the flip-flop (normal operation), or not.
Figure 337. LUT calculation table example
When some inputs are disabled in the “Logic Element Settings”, the table is simplified. All inputs remain visible, but unused ones are marked with “x”.
In the previous representation in[3] and in[1] are enabled, in[2] and in[4] are disabled.
In the next representation all the inputs are enabled.
Figure 338. LUT inputs enabled
• Inputs: Up to 16 inputs are selectable from GPIOs and internal signals, each input can be customized and synchronized.
• Outputs: PLAY GPIOs are selectable as outputs, with options for registered or direct output.
• The signal interconnect matrix is product-specific and unique to each STM32 derivative.
• Only one GPIO input per PLAY input is permitted.
4.20.5 Configuration in STM32CubeMX
The PLAY IP can be enabled by selecting the checkbox in the Logic Array section.
Configure inputs and outputs are configured in the Pinout & Configuration tab.
Input settings include custom naming, minimum pulse width (bypass or 1-255), edge detection mode, and input source selection from the interconnect matrix.
Logic element settings allow the selection of inputs by category, such as input multiplexer outputs, software inputs, and output signals.
LUT values can be edited directly or via a popup helper.
Output MUX settings allow the selection of output sources (direct or registered), with a default disabled state.
NVIC settings allow the configuration of PLAY interrupt events.
STM32CubeMX validates configurations, for example, warns if a flag transition is set without kernel clock enabled.
4.20.6 Functional description
The PLAY logic array processes input signals by programmable LUTs to generate outputs.
Inputs can be filtered to ignore pulses shorter than a configured minimum width or to detect specific edge transitions.
Registered outputs are clocked by selectable clocks, to enable synchronous logic and state machines.
Outputs can generate flags. These flage can trigger interrupts handled by the processor.
Feedback loops enable complex finite state machine implementations.
The configuration interface in STM32CubeMX provides intuitive control over all parameters, to ensure valid setups.
4.20.7 Typical use cases
Custom logic implementation within STM32 MCUs without external FPGA/PLD.
Finite state machines for control applications.
Signal conditioning and filtering for asynchronous inputs.
Interrupt generation based on complex input conditions.
Embedded logic for industrial, automotive, or IoT applications that require low-latency logic.
4.20.8 Software and middleware support
PLAY configuration is generated by STM32CubeMX as initialization code (HAL and LL layers).
Arrays for input MUX, LUT settings, and output MUX are created in MX_PLAY1_Init function.
Disabled sources are not generated in code.
HAL and LL drivers support the configuration of inputs, LUTs, and outputs.
STM32CubeMX generates code that is consistent with the configured parameters. The generated code includes synchronization and interrupt setup.
4.20.9 Example configuration and code snippet
Input mux settings
Configure inputs from GPIO and internal signals. The INPUT0 is configured in the example below.
Set the minimum pulse width and edge detection for filtering.
LUT Settings (Look Up Table 0 is configured in the example) Enable inputs used in LUT calculation.
Use the pop-up window to calculate LUT truth table values.
Output mux Settings
Select output source as direct or registered signal.
Enable clock for registered outputs if filtering is used.
Code snippet generated by CubeMX (simplified):
/**
* @brief PLAY1 Initialization Function
* @param None
* @retval None
** */ static void MX_PLAY1_Init(void)**
{
** /* USER CODE BEGIN PLAY1_Init 0 */**
** /* USER CODE END PLAY1_Init 0 */**
** HAL_PLAY_IN_ConfTypeDef configINPUTs[CONFIGURED_INPUT_NBR]; HAL_PLAY_LUT_ConfTypeDef configLUTs[CONFIGURED_LUT_NBR];**
** HAL_PLAY_OUT_ConfTypeDef configOUTPUTs[CONFIGURED_OUTPUT_NBR];**
** /* USER CODE BEGIN PLAY1_Init 1 */**
** /* USER CODE END PLAY1_Init 1 */**
** hplay1.instance = PLAY1;**
** if (HAL_PLAY_Init(&hplay1) != HAL_OK)**
** {**
** Error_Handler();**
** }**
** /** Configure Input 0**
** */ configINPUTs[0].min_pulse_width = 0; configINPUTs[0].mode = HAL_PLAY_EDGE_DETECTION_BYPASSED; configINPUTs[0].source = HAL_PLAY1_IN_TIM3_TRGO_MUX0;**
** if (HAL_PLAY_INPUT_SetConfig(&hplay1, configINPUTs, CONFIGURED_INPUT_NBR) != HAL_OK)**
** {**
** Error_Handler();**
** }**
** /** Configure the Logic Element 0**
** */ configLUTs[0].lut = HAL_PLAY_LUT0; configLUTs[0].truth_table = 0x88;**
** configLUTs[0].input_source[HAL_PLAY_LUT_INPUT0] = HAL_PLAY_LUT_INPUT_SWTRIG15;**
** configLUTs[0].input_source[HAL_PLAY_LUT_INPUT1] = HAL_PLAY_LUT_INPUT_SWTRIG15;**
** configLUTs[0].input_source[HAL_PLAY_LUT_INPUT2] = HAL_PLAY_LUT_INPUT_LUT0_OUT_DIRECT;**
** configLUTs[0].input_source[HAL_PLAY_LUT_INPUT3] = HAL_PLAY_LUT_INPUT_SWTRIG15; configLUTs[0].clk_gate_source = HAL_PLAY_LUT_CLK_GATE_OFF;**
** if (HAL_PLAY_LUT_SetConfig(&hplay1, configLUTs, CONFIGURED_LUT_NBR) != HAL_OK)**
** {**
** Error_Handler();**
** }**
** /** Configure Output 0**
** */ configOUTPUTs[0].output_mux = HAL_PLAY_OUT0; configOUTPUTs[0].lut_output = HAL_PLAY_LUT1_OUT_REGISTERED;**
** if (HAL_PLAY_OUTPUT_SetConfig(&hplay1, configOUTPUTs, CONFIGURED_OUTPUT_NBR) != HAL_OK)**
** {**
** Error_Handler();**
** }**
** /* USER CODE BEGIN PLAY1_Init 2 */**
** /* USER CODE END PLAY1_Init 2 */**
}
4.21 Notification Service
4.21.1 Introduction
The Notification Service in STM32CubeMX allows users to subscribe to notifications, updates, or premium content when downloading or installing STM32 software.
The objective is to obtain user consent to allow ongoing communication related to STM32 software, such as new releases and documentation updates.
Behavior overview:
• The Notification Service window in STM32CubeMX is accessible via a tab named Notification Service under the help menu, then Connection & Updates option.
Figure 339. Notification Service window in STM32CubeMX
• A subscription proposal for the software is triggered if the user tries to download or install it (If there is no existing notification subscription).
Figure 340. Popup appearing while installing a package for non-registered users
The Notification Service prompts the user to subscribe at the following entry points:
• When downloading an STM32Cube firmware package.
• When generating code.
• In the “Project Manager Settings” dialog.
• In the “Check for Update” window.
• In the Example Selector.
• In the Bootpath configuration.
• In the Third Parties window.
• In the “Connection & Updates” window.
The subscription proposal appears at each download attempt until the user selects “Don’t ask me again”.
Choosing “Don’t ask me again” automatically checks the “Hide notification service subscription prompt” box under the Notification Service window.
Figure 341. Hiding notification service prompt
Figure 342. Subscription proposal appearing while installing firmware
Users who want to subscribe must click the ‘Register’ button in the Notification Service window. This opens a registration form that must be completed to access the ‘Subscribe’ button. Once subscribed, users can:
• View their notification subscription status, including the current email address used.
• Update the notification subscription (change the email address).
• Clear the email address (see details below).
4.21.2 Subscription / Unsubscription
Subscription
To subscribe, the user must complete the registration form for the notification service.
• Subscription form elements:
– Email (mandatory):
The user provides an email address.
The form implements basic formatting validation to check the email syntax.
– Company (optional):
The user may provide a company name.
– Link to privacy notice:
The form includes a link to the ST standard corporate privacy policy.
– Checkbox to keep local history (if any exists):
Select this option to retain and associate previous local download history with the new subscription.
Figure 343. Register form
Subscription requirements
• A valid and operational email address.
• The user must have access to the email inbox used for the subscription.
The subscription starts only after the user validates the email address by clicking on the verification link sent to the inbox.
Figure 344. Popup for email validation
Figure 345. Email validation
• After the user selects the Validate now button in the received email, the browser redirects the user to an ST web page that displays the subscription details.
Figure 346. ST Web page to validate the subscription
This process prevents users from subscribing using someone else’s email address.
Note: Subscription to the Notification Service does not require any account creation on st.com.
Figure 347. The view of Notification Service tab after a user subscription
Subscription flow
• When the end-user subscribes to the Notification Service:
– The user’s credentials are saved under the user’s home folder.
– Each subsequent software download from STM32CubeMX (Software download history) is included in the user’s preferences and notification.
– Prior to email verification, the STM32CubeMX generates a local file to save the user’s preferences.
– When the user validates the email, the local history is removed from the user’s machine.
– The download history is displayed on the subscription page “My Subscriptions - STMicroelectronics” (the user should log with an account).
Figure 348. The subscription page
• The user can handle the preferences in the following page “My Communication preferences - STMicroelectronics”
• STM32CubeMX exposes the subscribed email address in its UI so that the user can:
– Update it to fix a typo, or change email for example.
– Clear it (see next section).
Figure 351. The user name exposed in the Notification Service window after email validation
4.21.3 Clearing the email in STM32CubeMX
If the user clears the email address in STM32CubeMX:
STM32CubeMX stops sending the software download history to the backend database. • The user’s existing subscription to notifications is not automatically canceled. Notifications may continue according to the configuration stored on the server side (preferences center / st.com).
Clearing the email in STM32CubeMX is a local application action and is not necessarily propagated as an unsubscription to the backend database.
4.21.4 Unsubscription
Unsubscription from notifications occurs through links provided in notification emails.
Each notification email will contain:
• A direct link to an unsubscribe page.
• A link to the Preference Center (under login on st.com), where the user can manage all the preferences and notifications.
The Preference Center is responsible for the actual activation/deactivation of email notifications.
Figure 354. The unsubscription action
4.21.5 Notification logic of firmware and software preferences
Start of notifications
After successful email validation, notification sending starts. The user must click the link sent to the inbox to validate the email address.
Frequency
Notifications are sent on a weekly basis at most.
A weekly email is sent only if there are changes relevant to the user’s preferences.
Notification content
Each notification email may include:
• New versions of preferred STM32 software such as STM32Cube firmware packages and so on.
• New versions of technical documents associated with the user’s software preferences.
• A link to the product folder on st.com
– This implies that the new software version is published on st.com.
• A summary of the user preferences (software and other preferences).
The email explicitly mentions that the software can be downloaded directly inside
STM32CubeMX.
Links in notification Email
At the bottom of the notification email, there are two links:
1. Unsubscribe
Stop the notification subscription according to backend rules.
2. My preference center
A link to the full preference center on st.com (under login).
The user can manage and update:
– All subscriptions,
– All notification channels,
– All software and other preferences.
4.22 About window