cancel
Showing results for 
Search instead for 
Did you mean: 

STM32CubeMX 6.2.1 for NUCLEO-H745ZI-Q doesn't generate PeriphCommonClock_Config() when ADC clocked by PLL3

CHossack
Associate III

I create a STM32CubeMx project (test.ioc) for a NUCLEO-H745ZI-Q board and select PPL3 to clock the ADC, but the function PeriphCommonClock_Config() is not generated unless I also clock the USB from PPL3 as well.

After enabling a single ADC1 channel I change the clocking as shown below

0693W00000Bd2GXQAZ.pngI then toggle the clock source for the USB and captured the code generated for each option as shown below. Left side is ADC clocked by PLL3, right side is is ADC and USB clocked by PLL3

0693W00000Bd2HLQAZ.pngSo it looks like STM32CubeMx is ignoring the generation of PeriphCommonClock_Config() when only the ADC is clocked from PLL3.

I think this is a bug in STM32CubeMX code generation.

cheers

Chris

1 ACCEPTED SOLUTION

Accepted Solutions

Hello  @CHossack​ ,

Let me thank you first for your feedback :smiling_face_with_smiling_eyes:

If I've correctly understood your post, PeriphCommonClock_Config() function is only generated when the PLL is the common clock source for two peripherals (PLL3 is used as the clock source for both ADC and USB in your case).

Actually, this is the expected behavior of STM32CubeMX. As indicated by its name PeriphCommonClock_Config() function is used for Peripherals Common Clock Configuration i.e. when two or more peripherals share the same clock source.

To sum up, STM32CubeMX assure the generation of two kind of configurations:

  • In case the PLL is used only by one peripheral : The clock structure will be filled and called in the MSP of the peripheral HAL (stm32h7xx_hal_msp.c).
  • In case the PLL is used by several peripheral (Shared clock): The clock structure shall be filled and the HAL_RCCEx_PeriphCLKConfig() should be called once in the PeriphCommonClock_Config (in main.c file). Nothing will be generated in the MSP regarding the peripheral clock.

Hope that I've answered your question. If this the case, please close this post by clicking the Select as Best button on my reply . This will help other members of the community find this response more quickly :)

Do not hesitate to raise any issue/ feedback.

Khouloud.

View solution in original post

3 REPLIES 3
Imen.D
ST Employee

Hello @CHossack​ ,

This post is related to CubeMx tool, so I added topic "STM32CubeMX" to your post in order to increase its chance to be reviewed by our CubeMx team.

Hello @Khouloud ZEMMELI​ , @Khouloud OTHMAN​ ,

Can you please check this issue ?

Imen

When your question is answered, please close this topic by clicking "Accept as Solution".
Thanks
Imen

Hello  @CHossack​ ,

Let me thank you first for your feedback :smiling_face_with_smiling_eyes:

If I've correctly understood your post, PeriphCommonClock_Config() function is only generated when the PLL is the common clock source for two peripherals (PLL3 is used as the clock source for both ADC and USB in your case).

Actually, this is the expected behavior of STM32CubeMX. As indicated by its name PeriphCommonClock_Config() function is used for Peripherals Common Clock Configuration i.e. when two or more peripherals share the same clock source.

To sum up, STM32CubeMX assure the generation of two kind of configurations:

  • In case the PLL is used only by one peripheral : The clock structure will be filled and called in the MSP of the peripheral HAL (stm32h7xx_hal_msp.c).
  • In case the PLL is used by several peripheral (Shared clock): The clock structure shall be filled and the HAL_RCCEx_PeriphCLKConfig() should be called once in the PeriphCommonClock_Config (in main.c file). Nothing will be generated in the MSP regarding the peripheral clock.

Hope that I've answered your question. If this the case, please close this post by clicking the Select as Best button on my reply . This will help other members of the community find this response more quickly :)

Do not hesitate to raise any issue/ feedback.

Khouloud.

CHossack
Associate III

Hi Khouloud,

Thank you for your explanation. That makes perfect sense.

cheers

chris