CubeMX 6.13.0 and MCU Package H7 v1.12.0 produce incorrect PCLK frequencies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-12-02 08:49 AM
I updated to CubeMX 6.13.0 and firmware package 1.12.0 for and STM32H755BIT chip and found several issues with the new release:
- Where is it documented that the new ExitRun0Mode() requires 'USE_PWR_LDO_SUPPLY" to be defined if I want to use that mode? Shouldn't it be defined by CubeMX when the power parameters are selected in the RCC section?
- If I am using the Voltage regulator in the LDO supply mode (see RM0399, p 274, Fig. 22, Section 1), what is the purpose of defining SMPS in line 217 of stm32h755xx.h? In line 440 of system_stm32h7xx_dualcore_boot_cm4_cm7.c the define of SMPS is used to disable the SMPS - shouldn't the define be used to enable the SMPS?
- Worst issue: The clock rates returned from PCLK function calls shown below are now showing 240 MHz! This has messed up the USARTs and all the timers. I thought the MAX clock rate for the PCLK clocks were 120 MHz (see DS12919, p. 110, Table 23, fPCLK, at VOS0 setting).
HAL_RCC_GetPCLK1Freq();
HAL_RCC_GetPCLK2Freq();
Screen capture showing 240 MHz clock rate on PCLK:
- Labels:
-
Bug-report
-
STM32CubeMX
-
STM32H7 Series
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-12-03 03:46 PM
It is defining both USE_PWR_LDO_SUPPLY and USE_PWR_DIRECT_SMPS_SUPPLY in the generated CMake file. It should only define USE_PWR_DIRECT_SMPS_SUPPLY since that's the selected power mode in CubeMX. I believe this is just a bug with STM32CubeMX code generation.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-12-03 04:06 PM
If I bump your SYSCLK to 280 MHz (max value) the generated CMakeList.txt file only contains:
target_compile_definitions(stm32cubemx INTERFACE
USE_PWR_DIRECT_SMPS_SUPPLY
USE_HAL_DRIVER
STM32H7B3xxQ
$<$<CONFIG:Debug>:DEBUG>
)
It is confusing how and what the different options are.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-12-03 04:09 PM
That's very interesting. On my original project I ran into this issue, I have the clock set to 280 MHz. I can't share that IOC file unfortunately, but it seems like there's a bunch of things happening in the background that may effect this issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-12-04 10:59 AM
The requirement for the new defines are discussed in the Main Changes section of the Release Notes for H7 Firmware:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-12-04 11:25 AM
@Ghofrane GSOURI is ST aware of the issue I mentioned (CubeMX creating multiple different USE_PWR* definitions) so that it may be fixed in a future version of STM32CubeMX?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-12-05 01:11 AM
Hello @cvanbeek
I Couldn't reproduce the issue with a new project starting from scratch but a ticket has been raised to dev team for further investigation to identify the root cause of this behavior (internal ticket number 197797 )
THX
Ghofrane
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-12-05 07:39 AM
Hi @Ghofrane GSOURI,
Thank you for noting the issue. Here's more info on my environment and the example I generated with this issue.
Environment:
- Windows (we've reproduced this on Windows 10 and Windows 11)
- STM32CubeMx version 6.13.0
- STM32Cube FW_H7 V1.12.0
Steps to generate a project with the error:
- Create a new project for STM32H7B3LIH6Q in CubeMX
- Select 'No' when asked about configuring MPU
- Give the project a name
- Change the toolchain/IDE to 'CMake'
- The RCC tab already has the supply set to PWR_DIRECT_SMPS_SUPPLY, so no change is needed there
- Click 'Generate Code'
The resulting cmake/stm32cubemx/CMakeList.txt file has the incorrect USE_PWR_LDO_SUPPLY definition:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-12-16 07:26 AM - edited ‎2024-12-16 07:38 AM
I see ST updated the FW_H7_1.12.1 package:
STM32CubeH7 Firmware Package V1.12.1 / 06-December-2024
Main Changes
- General updates to fix known defects and enhancements implementation.
- Fix wrong computed clock frequencies in HAL RCC driver.
I'll try it out and see if it fixed the clock issue I was having.
Edit: tagging @Ghofrane GSOURI
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-12-17 12:44 PM
After upgrading to CubeMX 6.13.0 and FW_H7_v.1.12.1, I got the following error: undefined reference to `ExitRun0Mode'.
system_stm32h7xx_dualcore_boot_cm4_cm7.c was not regenerated at all. I need to delete it to trigger the generation of a new system_stm32h7xx_dualcore_boot_cm4_cm7.c
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-12-19 01:36 AM - edited ‎2024-12-19 01:42 AM
Same here. When regenerating with CubeMX 6.13.0, some functions disappear. These were present on the first generation of code. Re-generating deletes them and build fails. However, this is not always the case. Sometimes re-generation does work. Not sure how to reliably repeat this.
If it fails, what is missing is `ExitRun0Mode'