STM32CubeMX errata 6.15.x

This message will disappear after all relevant tasks have been resolved.
Semantic MediaWiki
There are 1 incomplete or pending task to finish installation of Semantic MediaWiki. An administrator or user with sufficient rights can complete it. This should be done before adding new data to avoid inconsistencies.

1. Main fixed issues for 6.15.0

ID Summary
204758 When configuring the DCMI peripheral with an STM32N6 project, the initialization code of the DCMI IP is not generated for either the secure or non-secure domains.

The correction for this matter was provided with STM32CubeMX 6.15.0.

207079 When generating code for the STM32U375VEI project with all ADF (Audio Digital Filter) modes enabled and the option "Generate peripheral initialization as a pair of '.c/.h' files per peripheral" activated, a missing definition of the macro "IS_ADF_INSTANCE" leads to a build error.

The issue was treated in STM32CubeMX 6.15.0 release

207356 Missing code generation encountered while configuring the FLASH feature of an STM32H562 microcontroller using STM32CubeMX 6.14.0 more precisely enabling the SRAM13_RST option in the Flash Option Bytes.

The STM32CubeMX 6.15.0 integrates the solution for this issue.

208115 When generating code with STM32CubeMX v6.14.0 for the NUCLEO-H723ZG board with CORDIC peripheral enabled and both read/write DMA streams configured, the generated HAL_CORDIC_MspInit() function incorrectly links the DMA handles of the read and write streams. Specifically:
  • hdma_cordic_wr (write stream) is incorrectly linked to hdmaOut instead of hdmaIn.
  • hdma_cordic_rd (read stream) is incorrectly linked to hdmaIn instead of hdmaOut.

Resulting in incorrect DMA behavior at runtime.

The STM32CubeMX 6.15.0 contains the fix for this issue

208214 Users were unable to perform some NetXDuo UDP server settings on the STM32N6 products, more specifically on Nucleo-N657X0-Q board (no automatic support of Ethernet interface, missing driver paths, missing some VLAN configurations.

In STM32CubeMX 6.15.0 the configuration of the NetXDuo UDP server can be done without any issues.

210419 When creating a project for the NUCLEO-U5A5ZJ-Q board in STM32CubeMX v6.14.1 without Trust Zone,enabling the BSP and configuring PC13 as GPIO_EXTI13 causes a build error. Specifically, the generated EXTI13_IRQHandler() in stm32u5xx_it.c references an undeclared items,leading to a compilation failure.

The STM32CubeMX 6.15.0 solves this issue

2. Known limitations

  • When integrating software packages, please note that the current configuration only allows the selection of one major component at a time. Attempting to select packages like X-CUBE-TOUCHGFX and X-CUBE-TCPP together will be prevented by the package selector
  • when the user creates an .ioc file using STM32CubeMX 6.14.1 and then immediately imports it into the official STM32CubeMX version 6.15.0, selecting CONTINUE will cause an issue. Specifically, when accessing the old database, an extra folder is added to the database path so that STM32CubeMX fails to point the data.
    • Workaround: The user should copy the "db" folder from the extra added directory back to the original location atC:\Users\user_name\.stm32cubemx\databases\DB.6.0.141.
  • Regardless of the STM32CubeMX version, after refreshing data, the series filter in the Product Info section does not apply the selected criteria to the displayed product list.
  • An issue may appear with the MDK-ARM when the assembly file settings are modified from the "Option for Target'<project_name>" panel more precisely when the user add an include paths or defines from that panel it's going to be removed
    • As a temporary workaround, users can manually add include paths or defines for assembly files by stepping as listed here:
  1. Right-click on the assembly file and select "Options for File'startup_stm32XXXxx.s"
  2. Navigate to the Asm tab and add the necessary include paths and/or defines
asm option.png
  • Generating an STM32 project with a minimum version of EWARM toolchain creates a permanent association, disallowing the user from changing this minimum version later and regenerating the project.
  • For STM32 projects using the ThreadX with starm-clang compiler, the user may face a build issue.
  1. with STM32C0/STM32U0 products.
  2. The Expansion Packages providing the X-CUBE-AZRTOS for the following products STM32G0, STM32G4, STM32H7, STM32H7RS, STM32L4, STM32L5, STM32WB, STM32WL.

To have a functional Threadx with starm-clang compiler the user should proceed as follows:

  1. Copy “Middlewares/ST/threadx/ports/cortex_m0/ac6” folder from the STM32Cube firmware to the project
  2. Update the CMakeLists.txt file under “cmake/stm32cubemx/” by replacing “/gnu/” with “/ac6/”
  3. When using the Expansion Packages supporting X-CUBE-AZRTOS there's an extra step => Update the tx_initialize_low_level.S file under "Core/Src/"as illustrated here:
#if defined  (__clang__)                            to be replaced by ==> #if defined (__ARMCC_VERSION)

#if (defined(__GNUC__) && !defined(__clang__))      to be replaced by ==> #if (defined(__GNUC__) && !defined(__ARMCC_VERSION))

Only for STM32G0 users should change the following instruction in the tx_initialize_low_level.S 

.text 32                  to be replaced by ==> .text
  • For the STM32 products supporting the ThreadX feature natively, the build of the projects that enable ThreadX in "Low Power Support"mode with Makefile or CMake toolchains results in warnings.
  • The compare Projects tool cannot compare projects for which the DMA (Direct Memory Access) feature is enabled.
  • From Ubuntu version 23.10 and subsequent, when using CAD > tools then selecting 'MCU commercial part number' to configure CAD > MCU selector, the CAD viewer is not functional.
  • In the case of file access issue during a compilation with some examples on partner IDEs (for instance with the “cannot open-source input file” error message), consider to move either the full package manually, or just the example. For the example, use the Example Selector from STM32CubeMX, closer to the root of the disk (long path issue).
  • If “CAD resources” feature is not fully functional when using “Use System Proxy parameters”, try to use the “Manual Configuration of Proxy Server” or “No proxy” instead. (Menu : [Updater Settings…]>[Connection Parameters])
  • When unzipping a package on a macOS® system, use an official macOS® application such as the default graphical archive application, or the ditto tool in the command line:
    $ditto -x -k setupArchive.zip
    If a Linux®-like application is used (such as unzip), the expanded files lose the signature and are not recognized as signed.
  • For users of Keil® MDK, particularly those utilizing STM32CubeMX generated projects, a critical update regarding default toolchains is in effect. Starting with Keil® MDK version 5.37, Arm Compiler 6 (AC6) has become the default, superseding the deprecated Arm Compiler 5 (AC5). This change introduces a compatibility concern for specific STM32 products. Notably, STM32Fx, STM32L (0x, 1x, 4x), STM32H7 (2x, 3x, 4x, 5x, Ax, Bx), STM32Gx, STM32WB (1x, 3x, 5x), and STM32MP15x series,Users may encounter compilation errors when using the AC6 compiler with the previously listed products. An error message appears to indicate that the required Arm Compiler is unavailable.
    • Workaround: By following the steps below, you can continue using Arm Compiler 5 and avoid potential issues with STM32 projects of the products listed previously:
  1. Download Arm Compiler 5 manually from https://developer.arm.com/documentation/ka005198/latest/.
  2. Follow the step-by-step instructions available in this guide [1] to add Arm Compiler 5 to Keil® MDK 5.37 or newer.
  3. Once installed, select AC5 as the Arm Compiler of your project settings.
AC5 compiler.png


Note: a. Arm and TrustZone are registered trademarks of Arm Limited (or its subsidiaries) in the US and/or elsewhere.

2.1. When selecting microcontrollers in the STM32C0 series

  • When generating code for the STM32C071K8U3 microcontroller using EWARM toolchain, the linker file incorrectly defines the __ICFEDIT_region_ROM_end__ symbol as 0x0801FFFF. According to the device's datasheet (DS14693 Rev 1:7),the STM32C071K8U3 has 64 KBytes of Flash memory,So that the user should set the ROM end address to 0x0800FFFF instead of 0x0801FFFF.
/*-Memory Regions-*/
define symbol __ICFEDIT_region_ROM_start__ = 0x08000000;
define symbol __ICFEDIT_region_ROM_end__   = 0x0800FFFF;
  • When generating code for the STM32C092RCT6 microcontroller using STM32CubeMX version 6.15.0, with FDCAN1 enabled and configured to use the HSE (Crystal/Ceramic Resonator) as its clock source, targeting the STM32CubeIDE toolchain, the resulting code omits essential RCC initialization settings—specifically the RCC_OSCILLATORTYPE_HSE flag.
    • To resolve this issue, the missing initialization instruction |RCC_OSCILLATORTYPE_HSE; should be manually added to the main.c file as illustrated below (Users should note that the added code is not preserved across subsequent code generations)
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI|RCC_OSCILLATORTYPE_HSE;
RCC_OscInitStruct.HSEState = RCC_HSE_ON;

2.2. When selecting microcontrollers in the STM32F7 series

  • When working on STM32F7 projects with USB OTG HS feature, the user should verify that the generation of usbd_conf.c file:
    • Add __HAL_RCC_USB_OTG_HS_ULPI_CLK_ENABLE() instruction for Internal Phy HS or External Phy modes.
    • Remove __HAL_RCC_USB_OTG_HS_ULPI_CLK_ENABLE() instruction for Internal Phy FS mode.

2.3. When selecting microcontrollers in the STM32G0 series

  • Regarding the cohabitation between USB and USB Power Delivery, the VID and PID of USB Power Delivery and USB are not automatically aligned. VID/PID values must be aligned manually.
  • When both the USB Power Delivery and FreeRTOS™ CMSIS_V1 middleware are enabled at the same time, the FreeRTOS™ eTaskGetState parameter must be enabled in the include parameters tab.

2.4. When selecting microcontrollers in the STM32G4 series

  • When attempting to create a new STM32G411 project using STM32CubeMX with the firmware "STM32Cube_FW_G4_V1.6.0", the project creation fails. Instead of generating a correctly structured project, the process terminates unexpectedly.

2.5. When selecting microcontrollers in the STM32H5 series

  • For STM32CubeMX projects that utilizes the NUCLEO-H563ZI board and modifies the Flash start address and size, the generated linker script do not update accordingly upon code regeneration. This causes memory configuration inconsistencies.
    • After regenerating the code in STM32CubeMX the user should edit manually:
      • The linker script file STM32H563ZITX_FLASH.ld to update the Flash ORIGIN and LENGTH with the desired start address and size.
  • The following configuration will be lost after migrating to STM32CubeMX version 6.15.0: An STM32H573ZITx project created with STM32CubeMX version 6.14.1, where the OctoSPI1 peripheral is enabled, the boot path is configured, and an MMT user application region is defined within the OctoSPI1-controlled memory range (0x90000000 to 0xA0000000). Additionally, the Application Regions Settings are applied to both the peripheral configuration and linker files.
    • Upon migration, a popup notification will inform the user about the MMT user application region lose. The Application Regions Settings will be disabled for both Peripherals and linker files Furthermore, the hardware memory range managed by OctoSPI1 will be split into two sub-regions:
      • The first region, labeled “External memory (OCTOSPI1)”, with a size of 2 bytes.
      • The second region, labeled “OCTOSPI1”, with a size of less than 256 Mbytes.
pop up.png

To avoid the issue the user is recommended to follow these steps:

  1. Increase the Memory Size parameter under Octospi1 Configuration tab to 2 Gbits (256 M Byte).
  2. Recreate manually the MMT user application region that was allocated to the memory range controlled by Octospi1
  3. Turn on the “Apply Application Regions Settings to Peripherals” and “Apply Application Regions Settings to Linker Files” toggle buttons in the MMT panel.
  • For STM32CubeMX 6.14.0 OEMiROT projects, the execution of provisionning.bat script might fail due to wrong file path settings.
    • To fix this failure:  the  user should  either keep the default boot path configuration in stm32CubeMX, or if it's necessary, edit env.bat and set oemirot_boot_path_project to %~dp0..\.
  • When migrating projects with OEM-iROT boot path from STM32CubeMX V6.8.x to STM32CubeMX V6.10.x or later releases, the user might need to reconfigure ROT_Provisioning.
  • The makefile generation no longer works as soon as the project structure is changed from "Secure Project only" or "Non Secure Project only" to "Secure Project and Non Secure Project enabled (dual project)".
  • In Microsoft® Azure® NetX Duo, some configuration flags, which are not used in the STM32Cube firmware package examples, might be nonfunctional when combined.

2.6. When selecting microcontrollers in the STM32H7 series

  • A linker File mismatch after project regeneration: When regenerating an STM32CubeIDE project for the STM32H7S78-DK board using the X-CUBE-AZRTOS-H7RS pack, the system incorrectly selects STM32H7S7L8HXH_default.ld as the linker file. The expected linker file is STM32H7S7L8HXH_ROMxspi2.ld. This issue occurs after any STM32CubeIDE project has been removed and subsequently regenerated.
  • The STM32H7RS ExtMemLoader projects using CMake as toolchain run into compatibility issues with Unix-style shell commands when trying to execute CMake postbuild script.

indeed, the CMake postbuild command uses bash, and if it's not found in the environment (such as VScode), the following issue is shown up: Error: 'bash' is not recognized as an internal or external command

To solve the issue, the user should install the bash executable bash.exe, add the installation path found under C:\Program Files to your system's Path environment variables (For example, C:\Program Files\Git\bin if you've installed Git Bash), then execute the post build script.

  • For STM32H7RS OEMiROT projects in STM32CubeMX 6.14.0, the execution of provisionning.bat script might fail due to wrong file path settings.
    • To fix this failure:  the user should either keep the default boot path configuration in stm32CubeMX, or if it's necessary, edit env.bat and set oemirot_boot_path_project to %~dp0..\.
  • For the projects using STM32H7B product lines, when activating the SAI feature the parameters are not displayed in the Configuration tab.
  • A compilation issue appears in the build of STM32H7RS examples that activate the TRACER_EMB utility due to a limitation in the size of TRACER_EMB_STRUCTURE_MEMORY_LOCATION buffer.(the issue appears whatever the used toolchain)
    • The solution involves modifying the linker file to allocate a larger non-cacheable Buffer memory region.
  • During the migration from an older STM32H7 project (created with STM32CubeMX version coming earlier than V6.13.0) to the STM32CubeMX V6.13.0, The following files aren't automatically updated:

system_stm32h7xx.c and startup_stm32h7nnxx.s which are needed for the correct initialization of the system power supply.

  • This limitation might appear: An early RAM access prior to the configuration of the system power supply which is not allowed.
    • For new projects created by STM32CubeMX v6.13.0 and later, those files are correctly updated.
    • The system power supply configuration is also kept in SystemClock_Config() to avoid runtime issue with existing projects.
    • The workaround :To successfully migrate the project:The user should Copy the new files from the firmware side and ensure that they are correctly included in the project. In addition he should verify the compiler compatibility: he should use the appropriate startup_stm32h7nnxx.s file for the chosen compiler.
  • For the STM32H7Sx microcontrollers in the STM32H7 series, when using the NUCLEO-H7S3L8 board, the boot path is not supported. It is only supported for STM32H7S78-DK board or custom boards with the same flash and same pin mapping.
  • For the STM32H7Rx microcontrollers in the STM32H7 series, the boot path is not supported and Debug authentication is disabled.
  • MDMA and HSEM are not supported in LL. Only HAL is supported.
  • When activating any mode under SPDIFRX:
    • The alternate function configuration code is not generated in the HAL_SPDIFRX_MspInit function in the stm32h7xx_hal_msp.c file.
    • Add the workaround code in the user section after “GPIO_InitStruct.Speed =GPIO_SPEED_FREQ_LOW;” as described in Table 2 depending on the channel and selected pin.
Table 2. Workaround for alternate function configuration code
Channel Selected pin Workaround code
IN0 PD7 /* USER CODE BEGIN alternate function configuration */
GPIO_InitStruct.Alternate = GPIO_AF9_SPDIF;
/* USER CODE END alternate function configuration */
PG11 /* USER CODE BEGIN alternate function configuration */
GPIO_InitStruct.Alternate = GPIO_AF8_SPDIF;
/* USER CODE END alternate function configuration */
IN1 PD8 /* USER CODE BEGIN alternate function configuration */
GPIO_InitStruct.Alternate = GPIO_AF9_SPDIF;
/* USER CODE END alternate function configuration */
PG12 /* USER CODE BEGIN alternate function configuration */
GPIO_InitStruct.Alternate = GPIO_AF8_SPDIF;
/* USER CODE END alternate function configuration */
IN2 PC4 /* USER CODE BEGIN alternate function configuration */
GPIO_InitStruct.Alternate = GPIO_AF9_SPDIF;
/* USER CODE END alternate function configuration */
PG8 /* USER CODE BEGIN alternate function configuration */
GPIO_InitStruct.Alternate = GPIO_AF8_SPDIF;
/* USER CODE END alternate function configuration */
IN3 PC5 /* USER CODE BEGIN alternate function configuration */
GPIO_InitStruct.Alternate = GPIO_AF9_SPDIF;
/* USER CODE END alternate function configuration */
PG9 /* USER CODE BEGIN alternate function configuration */
GPIO_InitStruct.Alternate = GPIO_AF8_SPDIF;
/* USER CODE END alternate function configuration */

2.7. When selecting dual-core microcontrollers in the STM32H7 series

  • Only Boot0 is supported: both cores boot at once.
  • Import from and to dual-core STM32H7 is not supported.
  • For memory-to-memory DMA or BDMA or MDMA configuration, the initialization code is generated for both cores.
  • OpenAMP issue when compiling under EWARM and MDK-ARM when OpenAMP is activated under STM32CubeMX:
    • To avoid link errors in OpenAMP when compiling in EWARM IDE, add the next four lines of code in the linker files (.icf):
/* Create region for OPENAMP */
define symbol __OPENAMP_region_start__ = 0x38000400;
define symbol __OPENAMP_region_size__ = 0xFC00;
export symbol __OPENAMP_region_start__;
export symbol __OPENAMP_region_size__;
  • To avoid link errors in OpenAMP when compiling in MDK-ARM IDE, add the next four lines of code in the linker files (.sct):
; ***** Create region for OPENAMP *****
.resource_table +0 ALIGN 4 { ; resource table
*(.resource_table)
}
; Shared Memory area used by OpenAMP
__OpenAMP_SHMEM__ 0x38000400 EMPTY 0xFC00 {}
  • OpenAMP under STM32CubeIDE needs linker file update:
    • The following lines must be added under the .ld file:
/* Specify the memory areas */
MEMORY
{
...
m_ipc_shm (RW) : ORIGIN = 0x38000400, LENGTH = 63K
}
/* Symbols needed for OpenAMP to enable rpmsg */
__OPENAMP_region_start__=ORIGIN(m_ipc_shm);
__OPENAMP_region_end__=ORIGIN(m_ipc_shm)+LENGTH(m_ipc_shm);

2.8. When selecting microcontrollers in the STM32L5 series

  • Arm® TrustZone® support:
    • Fixed default SAU is configured in the application partition_stm32l552xx.h and partition_stm32l562xx.h files.
    • Import does not work for TrustZone® projects (TZEN=1).
  • To facilitate the peripheral privilege configuration, from STM32CubeMX V6.2.0, the GTZC peripheral is split into two domains: secure and nonsecure. The side effect is that, in the case of project migration from a release version before V6.2.0, if GTZC is configured in both the secure and nonsecure domains with previously configured privilege peripherals on a nonsecure peripheral, this configuration is lost during the migration. The GTZC_NS privileges must be configured again.
  • Regarding the cohabitation between USB and USB Power Delivery, the VID and PID of USB Power Delivery and USB are not automatically aligned. VID/PID values must be aligned manually.

2.9. When selecting microcontrollers in the STM32N6 series

  • When attempting to assign a DMA request to USART6.The USART6 and GPDMA1 are enabled successfully (and a specific channel x under the GPDMA modes) in the USART6 configuration panel, but GPDMA1 channel's request selector disables (greys out) the USART6_TX and USART6_RX options. This prevents the direct GUI configuration of the request.
    • To establish the USART6 DMA link, the user should manually update the stm32n6xx_hal_msp.c file generated by STM32CubeMX as follows:

1/Add this declaration after #include "main.h" instruction extern DMA_HandleTypeDef handle_GPDMA1_Channelx;

2/Add the following piece of code and update the parameter's values depending on the application needs 

    /* USART6 DMA Init */
    /* GPDMA1_REQUEST_USART6_RX Init */
    handle_GPDMA1_Channelx.Instance = GPDMA1_Channelx;
    handle_GPDMA1_Channelx.Init.Request = GPDMA1_REQUEST_USART6_RX;
    handle_GPDMA1_Channelx.Init.BlkHWRequest = DMA_BREQ_SINGLE_BURST;
    handle_GPDMA1_Channelx.Init.Direction = DMA_PERIPH_TO_MEMORY;
    handle_GPDMA1_Channelx.Init.SrcInc = DMA_SINC_FIXED;
    handle_GPDMA1_Channelx.Init.DestInc = DMA_DINC_FIXED;
    handle_GPDMA1_Channelx.Init.SrcDataWidth = DMA_SRC_DATAWIDTH_BYTE;
    handle_GPDMA1_Channelx.Init.DestDataWidth = DMA_DEST_DATAWIDTH_BYTE;
    handle_GPDMA1_Channelx.Init.Priority = DMA_LOW_PRIORITY_LOW_WEIGHT;
    handle_GPDMA1_Channelx.Init.SrcBurstLength = 1;
    handle_GPDMA1_Channelx.Init.DestBurstLength = 1;
    handle_GPDMA1_Channelx.Init.TransferAllocatedPort = DMA_SRC_ALLOCATED_PORT0|DMA_DEST_ALLOCATED_PORT0;
    handle_GPDMA1_Channelx.Init.TransferEventMode = DMA_TCEM_BLOCK_TRANSFER;
    handle_GPDMA1_Channelx.Init.Mode = DMA_NORMAL;
    if (HAL_DMA_Init(&handle_GPDMA1_Channelx) != HAL_OK)
    {  Error_Handler();
    }
    __HAL_LINKDMA(huart, hdmarx, handle_GPDMA1_Channelx);


  • An issue may occur when building an STM32N6 project in STM32CubeIDE where the AppS context is added incrementally. Specifically, if the project is initially created with components enabled only in the EXTMEM and FSBL contexts—but not in AppS—and later these components are activated in the AppS context by modifying the *.ioc file and regenerating the code, the AppS project fails to build due to missing files in the STM32CubeIDE\Appli\Application\User\Core directory.
  • When using USBPD with STM32N6 projects,and generating code with MDK-ARM toolchain, compilation error occurs due to inconsistent compiler flags in the settings, For example the library USBPDCORE_NOPD_CM55_Keil is compiled with specific compiler flags that set the wchar_t size or enum packing,while other libraries and files in the project are compiled with different flags.
    • To fix this error the compiler option Short enums/wcharof the MDK-ARM project under Options for Target-> C/C++ (AC6) should be unchecked.
  • The STM32N6 ExtMemLoader projects using CMake as toolchain run into compatibility issues with Unix-style shell commands when trying to execute CMake postbuild script.

indeed, the CMake postbuild command uses bash, and if it's not found in the environment (such as VScode), the following issue is shown up: Error: 'bash' is not recognized as an internal or external command. To solve the issue, the user should install the bash executable bash.exe, add the installation path found under C:\Program Files to your system's Path environment variables (For example, C:\Program Files\Git\bin if you've installed Git Bash), then execute the post build script.

  • For the full configuration of the FMC feature and whatever the chosen mode with the STM32N6xx products, the stm32n6xx_ll_fmc.c file is not automatically included in the project. To avoid facing compilation errors the manual inclusion of this file is required.
  • To avoid linking issues with Keil® MDK-ARM when a USBX Core System is enabled, the following modes should be enabled :
    • "UX Host HS1" or "UX Device HS1" if USB1_OTG_HS IP is used.
    • "UX Host HS2" or "UX Device HS2" if USB2_OTG_HS IP is used.
  • Warning messages appear after building a project that configure the ThreadX with 'Low Power Support' mode, regardless of the toolchain.
  • In the full LL mode, the function that activates the VddIOx power domain LL_PWR_EnableVddIOx() is missing from STM32CubeMX generated code. Consequently, there's no signal in some pins. (Note that for LL_PWR_EnableVddIOx() and VddIOx the x could be 2,3,4,5 depends on the activated power domain)
    • To fix the issue the user should add manually the LL_PWR_EnableVddIOx() in the main() after calling SystemClock_Config() when working in full LL mode.

2.10. When selecting microcontrollers in the STM32U5 series

  • An issue may be encountered, after upgrading the X-CUBE-FREERTOS package from version 1.3.0 to 1.3.1, after the upgrade all of the CMSIS-RTOS2 Tasks and Queues are no longer visible in the "Tasks and Queues" tab within the project's configuration.
  • A preprocessor error occurred in the compilation of STM32U5 projects because the #include statements in main.h were not properly delimited by newlines (more precisely including "stdio.h" in main.h with no line ending).
  • Regarding the cohabitation between Azure® RTOS USBX and USB Power Delivery, the VID and PID of USB Power Delivery and USBX are not automatically aligned. VID/PID values must be aligned manually.
  • To avoid linking issues with Keil® MDK-ARM when a USBX Core System is enabled, "Device CoreStack FS" or "Host CoreStack FS" must be enabled according to the USB_OTG_FS selected mode.
  • To avoid compilation issues when one DMA channel request is activated for one TIMx peripheral, replace htim_xx by htim_base. For example, replace:
    __HAL_LINKDMA(htim_oc, hdma[TIM_DMA_ID_CC1], handle_GPDMA1_Channel11);
    by
    __HAL_LINKDMA(htim_base, hdma[TIM_DMA_ID_CC1], handle_GPDMA1_Channel11);
  • In Microsoft® Azure® NetX Duo, some configuration flags, which are not used in the STM32Cube firmware package examples, might be nonfunctional when combined.


2.11. When selecting microcontrollers in the STM32WB series

2.11.1. When selecting microcontrollers in the STM32WB0 product lines

  • The following expansions packages for STM32Cube are not supported by microcontrollers from the STM32WB0 product lines:
    • X-CUBE-NFC10
    • X-CUBE-NFC9
    • X-CUBE-NFC4
    • X-CUBE-NFC10
    • X-CUBE-NFC6
    • X-CUBE-WB05N
    • X-CUBE-IPS
    • X-CUBE-TCPP
    • X-CUBE-SAFEA1
    • X-CUBE-GNSS1
    • X-CUBE-SUBG2
    • X-CUBE-EEPRMA1
    • X-CUBE-TOF1
    • X-CUBE-ALS
    • X-CUBE-BLEMGR
    • X-CUBE-ISPU
    • X-CUBE-BLE1
    • X-CUBE-BLE2
    • X-CUBE-MEMS1
    • X-CUBE-SFXS2LP1


2.11.2. When selecting microcontrollers in the STM32WB5 product lines

  • The STM32CubeMX 6.15.0 fails to create or migrate the STM32WB5M projects that configure QUADSPI using the MMT (Memory Management Tool) due to some issues in parsing the QUADSPI Start Address.

2.11.3. When selecting microcontrollers in the STM32WBA product lines

  • The WPAN BLE_simple configuration is dedicated for highly basic projects, essentially those with just a single operational loop in their main.c file. Therefore, when setting up a project in STM32CubeMX with multiple loops, the user shouldn't enable the FreeRTOS feature.
  • Some unexpected behaviors might appear during the creation of STM32WBA63 project: a non-updated STM32_WPAN Advertising elements menu, erroneous warnings at the peripheral configuration, and failures of IOC file reopening that lead to STM32CubeMX's home screen.
  • When the selected middleware is STM32WPAN for Bluetooth® Low Energy with the parameter CFG_BLE_NUM_LINK set above 8, use the Bluetooth® Low Energy link layer library LinkLayer_BLE_Basic_20_links_lib.a with the header file from the path \link_layer\ll_cmd_lib\config\ble_basic_20_links.
  • When building the BLE_Audio_TMAP_Central example for the STM32WBA55G-DK1 in STM32CubeIDE after being processed by STM32CubeMX, some library files might be missing or incorrectly referenced, leading to build errors.
    • To ensure proper library inclusion after installing the example, choose one of the following methods:
  1. Enable Library Copying: In the Project Manager tab, under "Code Generator > STM32CUBE MCU packages and embedded software packs," check the option "Copy all used libraries into the project folder."
  2. Manually Update Paths: In the .extSettings file, replace all instances of paths starting with ../Middlewares with ../../../Repository/STM32Cube_FW_WBA_Vx.x.x/Middlewares.
    • Example 1: Change ../Middlewares/ST/STM32_WPAN/ble/audio/Inc to ../../../Repository/STM32Cube_FW_WBA_Vx.x.x/Middlewares/ST/STM32_WPAN/ble/audio/Inc.
    • Example 2: Change Middlewares/STM32_WPAN=../Middlewares/ST/STM32_WPAN/ble/audio/lib/ble_audio.a to Middlewares/STM32_WPAN=../../../Repository/STM32Cube_FW_WBA_Vx.x.x/Middlewares/ST/STM32_WPAN/ble/audio/lib/ble_audio.a.
    • Note: The second workaround (Option 2) assumes the following default installation paths:
      • Example Path: C:\Users\USER_NAME\STM32Cube\Example
      • Firmware Path: C:\Users\USER_NAME\STM32Cube\Repository\STM32Cube_FW_WBA_Vx.x.x

2.12. When selecting microcontrollers in the STM32WL series

  • The user may face some compilation errors while generating an STM32WL dual-core project that enables the IPCC feature in Cortex-M0+ and uses STM32CubeIDE as a toolchain the error is due to a wrong definition of the CM0+ core symbol in the Preprocessor settings it was defined as CORE_CM0+ instead of CORE_CM0PLUS:
    • Error :'IPCC_C2_RX_C2_TX_IRQn' undeclared (first use in this function); did you mean 'IPCC_C1_TX_IRQn'? in ipcc.c/STM32WL55JCI7_CM0PLUS/Core/Src line 63 C/C++ Problem (error appears with the compilation of an STM32WL55JCI7 project).
    • To solve the issue the user should follow these steps
  1. In the project, right-click on the CM0+ target and navigate to Properties > C/C++ Build > Settings > MCU/MPU GCC Compiler > Preprocessor.
  2. Update the defined symbol from CORE_CM0+ to CORE_CM0PLUS.
  • If LoRaWAN®, SubGHZ_Phy or SigfoxTM middleware is used with the option Generate peripheral initialization as a pair of '.c/.h' files per peripheral disabled, it is advised to untick the visibility of the SUBGHZ and IPCC peripherals in [Project Manager]>[Advanced Settings] Generated Function Calls panel to avoid an issue when compiling.
  • Import from and to dual-core is not working for the STM32WL series.
  • For dual-core products, IPCC LL + RF middleware (LoRaWAN®, SigfoxTM, and SubGHZ_Phy) are not supported.
  • If a Sigfox project is generated with MDK-ARM, the following option must be set in the project Options C/C++(AC6) panel: Misc Controls: -fshort-enums
  • The SUBGHZ peripheral is forced on the Cortex®-M0+.
  • In the case of a project migration from a release version before V6.2.0, to facilitate the GTZC configuration, some previously default configuration ("enabled"/"disabled") has been moved to "default" configuration. This new state provides the default configuration of the MCU without any code generation. Users specifically needing this code generation must modify this state.
  • When compiling under IAR Embedded Workbench®, in case of dual-core products, the user must activate the share mode in both CM4 and CM0PLUS ST-LINK project options.
  • The "Time base: System tick timer" value selected in the NVIC configuration panel is not used for the code generation. This value must be updated by the end user in the generated code.
  • KMS and STM32Cube Azure® RTOS ThreadX cannot be enabled in the same core.

2.12.1. When selecting microcontrollers in the STM32WL33 product lines

  • The following expansions packages for STM32Cube are not supported by microcontrollers from the STM32WL33 product lines:
    • X-CUBE-NFC10
    • X-CUBE-NFC9
    • X-CUBE-NFC4
    • X-CUBE-NFC10
    • X-CUBE-NFC6
    • X-CUBE-WB05N
    • X-CUBE-IPS
    • X-CUBE-TCPP
    • X-CUBE-SAFEA1
    • X-CUBE-GNSS1
    • X-CUBE-SUBG2
    • X-CUBE-EEPRMA1
    • X-CUBE-TOF1
    • X-CUBE-ALS
    • X-CUBE-BLEMGR
    • X-CUBE-ISPU
    • X-CUBE-BLE1
    • X-CUBE-BLE2
    • X-CUBE-MEMS1
    • X-CUBE-SFXS2LP1

2.13. When selecting microprocessors in the STM32MP1 series

  • DMA nodes are generated in the device tree, but the DMA properties in the IP clients nodes are not generated.
  • Import from and to MPU projects does not work properly.
  • Dual-core project structure compatibility break : the action to import (migrate or continue) projects created with versions earlier than STM32CubeMX V5.3.0 is supported but requires the manual copy of USER SECTIONS for the device tree and Cortex®-M4 firmware from the former folder structure (DeviceTree/Inc/Src) to the new one (CA7/DeviceTree - CM4/Src - CM4/Inc).
  • Additional software is not supported.
  • RCC generation in Production mode is not supported on the coprocessor side. Only the Engineering mode is supported.
    By default, the STM32CubeMX-generated code is compliant with the Engineering mode. Therefore, the call of the following clock functions must be removed in the Production mode since these clocks are then managed by Linux®: SystemClock_Config(), PeriphCommonClock_Config(), and HAL_RCCEx_PeriphCLKConfig():
    • The system parts (SystemClock_Config() and PeriphCommonClock_Config()) can be removed in STM32CubeMX by selecting [Not Generate function call] for RCC in the Project Manager, then Advanced Settings tabs.
    • HAL_RCCEx_PeriphCLKConfig() must be removed manually from file stm32mp1xx_hal_msp.c (STM32CubeMX-generated code).
    • To make the user code compatible with both the engineering and production modes, the above RCC functions can be put under dynamic condition
      if(IS_ENGINEERING_BOOT_MODE()).
  • On macOS®, installation issues may result from the fact that the install is not signed. Use the following procedure:
    • Download STM32CubeMX on a Window® OS personal computer.
    • Copy the downloaded install into the macOS® personal computer.
    • Launch the install.
  • OpenAMP warning when compiling under MDK-ARM if OpenAMP is not activated under STM32CubeMX:
    • Remove the next four lines of code from the linker files (.sct) to avoid warning “No section matches pattern *(.resource_table)”:
; ***** Comment these 4 lines if OPENAMP is not used *****
.resource_table +0 ALIGN 4 { ; resource table
*(.resource_table)
}
; Shared Memory area used by OpenAMP
__OpenAMP_SHMEM__ 0x10040000 EMPTY 0x8000 {}
  • Device tree generation: the "pwr" user section name is changed to "pwr_regulators".
    • Existing code in the "pwr" user section must be backed up and reported manually into the new "pwr_regulators" user section after code generation.
  • About the HRTIM peripheral: for the "Set Source Selection" & "Reset Source Selection" parameters, the "No source is selected" must be manually set for any unused source before decreasing the number of sources.
  • When using the STM32CubeMP13 bare-metal firmware, the secure mode of the peripheral RTC is not available for the STM32MP13xx microprocessors. It is only available when the STM32CubeMP1 MCU package is used.
  • When using the STM32CubeMP13 bare-metal firmware and activating Azure® RTOS ThreadX, the STM32CubeIDE linker file must contain the following section to avoid compilation issues:
.stack:
{
 _stack_bottom = ABSOLUTE(.) ;
 /* Allocate room for stack. This must be large enough for the
 IRQ, FIQ, and SYS stack if nested interrupts are
 enabled.*/
 . = ALIGN(8) ;
 . += 32768 ;
 _sp = . - 16 ;
 _stack_top = ABSOLUTE(.) ;
 } >RAM
 _end = .;

2.14. When using the Memory Management Tool

  • For projects using STM32H573I-DK board with TrustZone feature enabled, the activation of the following Memory Management parameter 'Apply Application Regions Settings to peripherals' after initial code generation results in build failures.
  • Linker file issues may result from configuring MMT after the initial code generation (more precisely activating the MMT in the second code generation).
  • When using the Memory Management Tool in a project based on CMake or Makefile build generators, the following configurations are not supported:
    • The TrustZone activation.
    • The use of the STM32H7Rx/7Sx microcontrollers from the STM32H7 series.
  • For the projects based on STM32WB series and using the MMT, the generated linker file in not taking into account the activation of the option "Boot Info".
  • When setting the mode of the Extmem Manager in the boot runtime context, the Memory Management Tool generates only an 'Execute' memory region and omits the 'LOAD_REGION' one. The 'LOAD_REGION' is displayed as reserved in the UI. This limitation applies to all toolchains and IDEs.
  • The linker script is not automatically updated to incorporate the 'isrvercor' configuration.

2.15. When using the Example Selector

  • When generating STM32CubeMX (version 6.13.0) projects for RF applications of the STM32WB0x and STM32WBA5x series, with the STM32CubeIDE selected as a tool chain, users may encounter issues with the generated project structure. More precisely essential header files might be missing, resulting in compilation errors.
    • Workaround: To address this issue, it is recommended to regenerate the project within STM32CubeMX.
  • When starting an example from the Example Selector and regenerating the code, some files can be duplicated. It can lead to potential compilation issues. In this case, remove the duplicated files.

2.16. When using additional software packs

  • If a software component refers to a specific peripheral, this peripheral must be initialized with HAL APIs (not with LL APIs).
  • When using dual-core devices, if a software component refers to a specific peripheral, this peripheral must be assigned only to the same core as the software component.
  • When a pack is disabled, the generated files are not removed from the project. Workaround: remove these files manually.
  • Functionalities that are not supported:
    • maxInstances, isDefaultVariant, generator attributes of the component element
    • Dtz, Ddsp, Dsecure attributes of the condition element
    • repository element
    • tag and url attributes of a release element
    • dominate element
    • public attributes for the file element
    • preIncludeLocal and preIncludeGlobal file category attributes
    • Pre_Include_Local_h element
    • Pre_Include_Global_h element
    • Pack components where attribute values come with a "." character
  • Compilation issues when using both X-CUBE-AZRTOS-H7 v1.1.0 and OpenAMP middleware in the same project with minimum version MDK-ARM v5.32:
    X-CUBE-AZRTOS-H7 v1.1.0 requires Arm C compiler version 6 while OpenAMP is not compatible with this version (only Arm C compiler version 5 is supported). The workaround consists in using X-CUBE-AZRTOS-H7 v1.0.0 instead. This one is compatible with Arm C compiler version 5.
  • In the case of an error message when downloading SEGGER I-CUBE-embOS:
    • Download SEGGER.I-CUBE-embOS manually from the SEGGER download site at https://www.segger.com/downloads/embos.
    • Open the STM32CubeMX Embedded Software Packages Manager.
    • Use the option Load from Local and select the pack.

2.17. STM32CubeIDE toolchain

  • It is functional only with a Java 8 64-bit virtual machine with versions earlier than STM32CubeMX V5.6.1.

2.18. DDR test suite

  • STM32CubeProgrammer (STM32CubeProg) is not supported from v2.10.0 onwards.

2.19. User manual

  • Some chapters in the user manual STM32CubeMX for STM32 configuration and initialization C code generation (UM1718) are not fully up to date.

2.20. Symbolic links on Ubuntu

  • When using Ubuntu 20.04 if you use a symbolic link to refer to the "Firmware Relative Path" in the STM32CubMX Project Manager tab, it will be translated to the absolute path before saving down.

3. Recommendations

3.1. Command line authentication required

Since introduction of authentication at the command level, we recommend our costumers to review their scripts. They should make sure they are authenticating before trying to download a package or before trying to generate code on the command line. Failure to do so will result on errors displayed on the command line.

3.2. DDR binaries for the STM32MP1 boards

The DDR binaries needed to connect to the STM32MP1 boards are available from the GitHub website at https://github.com/ with the keyword STMicroelectronics/STM32DDRFWUTIL.

3.3. List pinout-compatible microcontrollers

The loading of microcontrollers can take a long time if all series and all packages are selected. If the loading takes too long, stop it, refine the microcontroller filters on a dedicated series or package, and restart the loading.

3.4. How to improve the wake-up from Stop sequences without relying on the global SystemClock_Config()

The SystemClock_Config provided in the HAL examples is intended to be used to configure the system clock at startup. It is not recommended to use it to restore the clock settings after a Stop mode.
To keep the wake-up as quick as possible, it is highly recommended to restore only what has been changed by the hardware to enter the Low-power mode. This is typically the case for the oscillators and system clock sources. The RCC configuration registers are unchanged, and there is no need to restore them.
Typically, after a Stop mode, it is recommended to call a separate SystemClockConfig_STOP after the wake-up that enables the LSE and PLL, and selects PLL as system clock source (LSE and PLL are disabled in Stop mode). Find below an example of SystemClockConfig_STOP (provided in the HID_Standalone_LPM application):

static void SystemClockConfig_STOP(void)
{
#if defined (USB_USE_LSE_MSI_CLOCK)
/* Configures system clock after wake-up from STOP: enable LSE,
PLL and select PLL as system clock source (LSE and PLL are disabled in Stop mode) */
__HAL_RCC_LSE_CONFIG(RCC_LSE_ON);
/* Wait till HSE is ready */
while(__HAL_RCC_GET_FLAG(RCC_FLAG_LSERDY) == RESET)
{}
/* Enable the main PLL. */
__HAL_RCC_PLL_ENABLE();
/* Wait till PLL is ready */
while(__HAL_RCC_GET_FLAG(RCC_FLAG_PLLRDY) == RESET)
{}
/* Select PLL as SYSCLK */
MODIFY_REG(RCC->CFGR, RCC_CFGR_SW, RCC_SYSCLKSOURCE_PLLCLK);
/* Wait till system clock switch to PLL */
while (__HAL_RCC_GET_SYSCLK_SOURCE() != RCC_CFGR_SWS_PLL)
{}
#elif defined (USB_USE_HSE_CLOCK)
/* Configures system clock after wake-up from STOP: enable HSE,
PLL and select PLL as system clock source (HSE and PLL are disabled in Stop mode) */
__HAL_RCC_HSE_CONFIG(RCC_HSE_ON);
/* Wait till HSE is ready */
while(__HAL_RCC_GET_FLAG(RCC_FLAG_HSERDY) == RESET)
{}
/* Enable the main PLL. */
__HAL_RCC_PLL_ENABLE();
/* Wait till PLL is ready */
while(__HAL_RCC_GET_FLAG(RCC_FLAG_PLLRDY) == RESET)
{}
/* Select PLL as SYSCLK */
MODIFY_REG(RCC->CFGR, RCC_CFGR_SW, RCC_SYSCLKSOURCE_PLLCLK);
/* Wait till system clock switch to PLL */
while (__HAL_RCC_GET_SYSCLK_SOURCE() != RCC_CFGR_SWS_PLL)
{}
#endif /* USB_USE_LSE_MSI_CLOCK */
}
Retrieved from "https://wiki.st.com/stm32mcu/index.php?title=STM32CubeMX_errata_6.15.x&oldid=81881"