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:

 

[Ghofrane GSOURI]

Hello @djanovy 

First let me thank you for posting.

Could you please share your IOC in order to check your configuration? This will help further the investigation.

THX

Ghofrane

[djanovy]

Version 6.12 and 6.13 .ioc files attached.  I'm also sending the main.c files and the simple post.c file that showed the PCLK frequencies at 240 MHz.  The main.com in this message is for the CM7 core.  This web interface only allows three files at a time, so I will include the other two files in the next message.

The first indicator that I noticed in my real application was the USART output data on the CM7 core was corrupted indicating an incorrect baud rate.

In the main.c files I have commented out the code where the two cores coordinate their boot sequence, allowing them to boot independently.  CTI option bytes are also set in the OpenOCD target config to prevent the cores from halting each other.

Let me know if there is anything else I can provide.

[Ghofrane GSOURI]

Hello @djanovy 

When configuring the Supply Source to :Power _LDO_Supply

The generated code using CubeMX 6.13.0 will be : 

void SystemClock_Config(void)
{
 RCC_OscInitTypeDef RCC_OscInitStruct = {0};
 RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};

 /** Supply configuration update enable
 */
 HAL_PWREx_ConfigSupply(PWR_LDO_SUPPLY);

calling HAL_PWREx_ConfigSupply(PWR_LDO_SUPPLY); prepares your microcontroller to use the LDO for power management. When ExitRun0Mode() is subsequently executed, it will configure the system to ensure that the LDO is enabled and ready, allowing for a smooth transition back to normal operational mode from a low-power state.

So no need for you to add anything.

I am looking forward to receiving your feedback and IOC.

THX

Ghofrane

[djanovy]

Just to clarify the sequence of function calls...

ExitRun0Mode() is called in startup_stm32h755xx_CM7.s, line 64:

/* Call the ExitRun0Mode function to configure the power supply */
 bl ExitRun0Mode
/* Call the clock system initialization function.*/
 bl SystemInit

before HAL_PWREx_ConfigSupply(PWR_LDO_SUPPLY) is called from main() -> SystemClock_Config():

void SystemClock_Config(void)
{
 RCC_OscInitTypeDef RCC_OscInitStruct = {0};
 RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};

 /** Supply configuration update enable
 */
 HAL_PWREx_ConfigSupply(PWR_LDO_SUPPLY);

ExitRun0Mode() from system_stm32h7xx_dualcore_boot_cm4_cm7.c checks for a define 'USE_PWR_LDO_SUPPLY'.  I do not see where this define gets set in any of the source code/header files.

void ExitRun0Mode(void)
{
#if defined(USE_PWR_LDO_SUPPLY)
 #if defined(SMPS)
 /* Exit Run* mode by disabling SMPS and enabling LDO */
 PWR->CR3 = (PWR->CR3 & ~PWR_CR3_SMPSEN) | PWR_CR3_LDOEN;
 #else
 /* Enable LDO mode */
 PWR->CR3 |= PWR_CR3_LDOEN;
 #endif /* SMPS */

 

[djanovy]

I found the 'USE_PWR_LDO_SUPPLY' define in the Makefile.  Since I don't use the CubeMX generated Makefile, I wasn't finding it.  For people in a similar situation it would help if there was an warning error if a specific supply mode is not selected similar to how CORE_CM7 is checked:

 

#if defined(DUAL_CORE) && !defined(CORE_CM4) && !defined(CORE_CM7)
 #error "Dual core device, please select CORE_CM4 or CORE_CM7"
#endif

 

I had previously added the define to my Symbol list and the testing done above included the define.

[cvanbeek]

I have a related problem but in a CMake project for STM32H7B3LIHxQ.  This project has SupplySource set to PWR_DIRECT_SMPS_SUPPLY in the RCC settings.  When generating the code, it defines BOTH USE_PWR_LDO_SUPPLY and USE_PWR_DIRECT_SMPS_SUPPLY in the CMakeLists.txt file.

[cvanbeek]

Here's a minimum example project with my replicated issue.  Note the definitions in cmake/stm32cubemx/CMakeLists.txt

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

[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]

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 

[Peter3718]

Hi, @djanovy 

I ran into same issue as you

1. RCC clock generation is wrong.

2. Both USE_PWR_LDO_SUPPLY and USE_PWR_DIRECT_SMPS_SUPPLY are defined.

Not understand why ST has sucu low level issue. After you tried out FW_H7_1.12.1, are these issue resolved?

Peter

[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' 

[CTapp.1]

Did you ever find a solution to this? I'm trying to build a TouchGFX sample for a Riverdi board, and I am getting:

undefined reference to `ExitRun0Mode'

and, as was noted above, the system_stm32h7xx_dualcore_boot_cm4_cm7.c file is only regenerated if I delete the original one.

I am using FW_H7_1.12.1.

Edited to add:

ExitRun0Mode is defined in (the regenerated) system_stm32h7xx_dualcore_boot_cm4_cm7.c, so it looks like it may not be getting pulled into the build (using cmake).

[toroid]

My solution was to take a detour and using the Before/After scripting offered by CubeMX. In Project Manager/Code Generator you can find user actions section with before and after code generation commands.

I made suitable scripts to preserve my original code and then restore it after cubemx finishes. This works nicely for things that you need to preserve.