CubeMX 6.13.0 and MCU Package H7 v1.12.0 produce incorrect PCLK frequencies

[djanovy]

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:

1. 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?
2. 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?
3. 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:

[cvanbeek]

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.

[djanovy]

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.

[cvanbeek]

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.

[djanovy]

The requirement for the new defines are discussed in the Main Changes section of the Release Notes for H7 Firmware:

Release Notes for STM32CubeH7 Firmware on Github 

[cvanbeek]

@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?

[Ghofrane GSOURI]

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

[cvanbeek]

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:

[djanovy]

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 

[peterdonchev]

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

[toroid]

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'