Last edited 2 weeks ago

STM32CubeMX release note

Applicable for STM32MP13x lines, STM32MP15x lines, STM32MP23x lines, STM32MP25x lines


1. STM32CubeMX 6.13.0 - MPU support[edit | edit source]

1.1. New features supported in this release[edit | edit source]

  • Support of STM32MP23x lines More info.png

1.2. Main changes[edit | edit source]

  • OpenSTLinux-v6.0.0 device tree generation
  • STM32CubeMP2-v1.1.0 code generation
  • DDR configuration improvements for RIF feature
  • Support of STM32MP235/3/1 lines
  • Support of STM32MP25 "TFBGA 361 16x16" packages

1.3. Main Restrictions[edit | edit source]

1.3.1. With STM32MP25x[edit | edit source]

  • The MDF1 IP can't be fully configured for the projects which are using STM32MP257F-DK Discovery kit More info green.png. It is partially configured in the STM32CubeMX user interface, but in the generated Device Tree the unconfigured parts are added in the User Section to avoid pin configuration redundancy.
  • When reloading an existing project using STM32MP257DALx MPU with the VFBGA361 10x10 Package, and the DDR_CTRL_PHY peripheral configured, the “package” parameter in the “Parameter Settings” tab is set 1 instead of 2 with a red cross, the user should adjust the value from 1 to 2 to get a working project.
  • The synchronization between the OSPI1/2 peripheral assignment and the RCC features OSPI1/2_CFGR assignment is not automatic; therefore, the OSPI1/2_CFGR feature assignment must be manually configured in the RCC module whenever OSPI1 or OSPI2 peripherals are used to ensure they receive the correct clock signals for proper operation.
  • The assignments of the RCC features OCTOSPIx_CFGR and xxxRAM_CFGR are not automatically synchronized with the assignments of their hardware resources (OCTOSPIx peripherals and RAM regions); therefore, these assignments must be done manually to ensure the hardware resources are correctly clocked. STM32CubeMX provides tips to help for each of these features.
  • IOM/OSPI: to handle properly the clocks when OSPIx is used in Multiplexed mode and OSPIy is not used, the (RCC) OSPIy_CFGR feature should have the same assignment as OSPIx_CFGR one.
  • When FMC is assigned to a Cortex®-M33 nonsecure Cube firmware (HAL & LL) context, the NVIC panel is not displayed.
  • Only STM32CubeIDE is supported.

1.3.2. With STM32MP13x[edit | edit source]

  • When using the STM32CubeMP13 bare-metal firmware and activating Azure® RTOS ThreadX or FreeRTOS, the user should Copy the startup_stm32mp13xxyy_ca7_rtos.c and system_stm32mp13xx_A7_rtos.c from the firmware side and ensure that they are correctly included in the project.
  • The limitations encountered with STM32CubeMx V6.12.0 regarding STM32MP13x persist in theSTM32CubeMx V6.13.0

1.4. How to compile device tree in OpenSTlinux[edit | edit source]

An example of the device tree, generated by STM32CubeMX, compilation, with OpenSTlinux, is described in How_to_compile_the_device_tree_with_the_Developer_Package article.


2. How to get STM32CubeMX[edit | edit source]

STM32CubeMX for Linux®, Windows® and macOS ®
Download

Version 6.13.0

  • Download the preferred all-in-one installer from www.st.com
    • Generic Linux® installer - STM32CubeMX-Lin
    • Windows® installer - STM32CubeMX-Win
    • macOS® installer - STM32CubeMX-macOS
Installation guide
  • Refer to the installation guide section of the STM32CubeMX user manual (UM1718) available on www.st.com.
User manual
  • When the installation is completed, see additional information about STM32CubeMX from www.st.com in the STM32CubeMX user manual (UM1718)
Detailed release note
  • Details about the content of this tool version are available in the STM32CubeMX release 6.13.0 release note from www.st.com

Minor releases may be available from the update site.


3. Archives Archive box.png[edit | edit source]

3.1. STM32CubeMX 6.12.1 - MPU support[edit | edit source]

3.1.1. Main fixed issues[edit | edit source]

The STM32CubeMX V6.12.1 solves the following issues:

  1. Device tree generation: Misconfiguration of some peripherals in the STM32MP257F-EV1 and STM32MP257F-DK ".ioc" files is causing issues in the device tree generation.
  2. DDR mapping: The address A19 cannot be assigned in DDR mapping.
  3. RCC configuration in Cortex®-M33: When configuring a peripheral in the Cortex®-M33 context, the FLEXCLKGEN settings for the RCC node in the device tree (DT) are not generated.

3.2. STM32CubeMX 6.12.0 - MPU support[edit | edit source]

3.2.1. New features supported in this release[edit | edit source]

  • Support of STM32MP25x lines More info.png

3.2.2. Features already supported in previous releases[edit | edit source]

  • Support of STM32MP13x lines More info.png
  • Support of STM32MP15x lines More info.png
  • Support for Azure RTOS ThreadX, FileX, LevelX, NETX and USBX, for STM32CubeMP13 package release

3.2.3. Main changes[edit | edit source]

  • Add new Intropack openstlinux-6.1-yocto-mickledore-mpu-v24.06.26 for STM32MPU (STM32MP1 series & STM32MP2 series).

3.2.4. Main Restrictions[edit | edit source]

3.2.4.1. With STM32MP25x[edit | edit source]
  • Only STM32CubeIDE is supported.
  • STM32CubeMX configurations (IOC) for STM32MP257F-EV1 Evaluation board More info green.png and STM32MP257F-DK Discovery kit More info green.png do not configure LTDC in secure mode (trusted UI is disabled). This differs from OpenSTLinux software configuration where the trusted UI is enabled for these boards.
  • The synchronization between OSPIx peripherals assignments and the RCC features OSPI1/2_CFGR assignments is not "automatically" performed. OSPI1/2_CFGR features assignments should be done whenever OSPI1/2 are used in order to clock correctly the peripheral(s).
  • The assignments of the RCC features OCTOSPIx_CFGR and xxxRAM_CFGR are not automatically synchronized with the assignments of their hardware resources (OCTOSPIx peripherals and RAM regions). These assignments should be done manually to clock correctly the hardware resources. STM32CubeMX displays tips helpers for each of these features.
  • In the pinout & configuration view, the U-Boot context assignments are not synchronized with the Linux® context assignments. Whenever a peripheral is assigned for U-Boot, it should be also assigned for Linux®. (the opposite is not true).
  • IOM/OSPI: to handle properly the clocks when OSPIx is used in Multiplexed mode and OSPIy is not used, the (RCC) OSPIy_CFGR feature should have the same assignment as OSPIx_CFGR one.
  • When FMC is assigned to a Cortex®-M33 nonsecure Cube firmware (HAL & LL) context, the NVIC panel is not displayed.
  • The device trees generated by STM32CubeMX for the STM32MP257F-DK Discovery kit More info green.png and STM32MP257F-EV1 Evaluation board More info green.png boards are fully functional. Although these device trees are close to the "STM32 MPU embedded software device tree" configuration, some differences may exist. Refer to the chapter External_device_tree for details on "STM32 MPU embedded software device tree".
  • When creating a STM32MP25 empty project, a partial configuration of the (RIF) RISAFx and RISABx sub-system is pre-filled. This configuration is the OpenSTLinux one but limited to the definition of the regions name and size (security not defined).

These are the complete OpenSTLinux configuration including security aspects:
RISAF1(BKPSRAM)

RISAF1(BKPSRAM)

RISAF2(OCTOSPI1&2)

RISAF2(OCTOSPI1&2)

RISAF4(DDR)

RISAF4(DDR)

RISAF5(PCIE)

RISAF5(PCIE)

RISAB1(SYSRAM1)

SYSRAM1(BKPSRAM)

RISAB2(SYSRAM2)

RISAB2(SYSRAM2)

RISAB3(SRAM1)

RISAB3(SRAM1)

RISAB4(SRAM2)

RISAB4(SRAM2)

RISAB5(RETRAM)

RISAB5(RETRAM)

RISAB6(VDERAM)

RISAB6(VDERAM)

3.2.4.2. With STM32CubeMP13 package[edit | edit source]
  • Only STM32CubeIDE is supported.
  • Only application context is supported.
  • Standard version of LevelX, USBX, NetX middlewares integrated without STM32MP13 platform specific patches.
  • When using the STM32CubeMP13 package 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 big enough for the
IRQ, FIQ, and SYS stack if nested interrupts are
enabled.*/
. = ALIGN(8) ;
. += 32768 ;
_sp = . - 16 ;
_stack_top = ABSOLUTE(.) ;
} >RAM
_end = .;