drivers: clock_control: stm32h7 cannot choose system frequency higher than 400MHz #27212
Comments
|
Thank you for opening this bug. I would leave for the first the OpenOCD flash problem outside of this bug: |
@Nukersson In my case, OpenOCD fails to succed with shutdown command invoked on my board because of the bugged clock configuration which prevents OpenOCD to communicate with the chip once it has executed the bugged code section which can freeze the clock tree in an unspecified state. That could also explain why I have to connect the device under reset to be able to flash another binary program. So it is not OpenOCD to blame in the first place but it is there to identify that we get the bug. |
Then it is even better, if we focus on fixing the clock bug. Afterwards we can investigate if OpenOCD/Flashing problem disappears. |
Exactly, OpenOCD will be part of our tests steps to validate the fixing PR 😄 I have updated the bug description to better show why OpenOCD could fail due to a bad clock configuration. |
|
I am facing same bug with my NUCLEO-H745ZI-Q board. This board is currently placed in master branch of Zephyr's repository. Per default this board uses PLL with HSE and 240MHz/480MHz clock for M4/M7 cores respectively. See the settings in My observations are: I. Investigating the buggy merge number:
lets the system work properly. Further increasing of II. Summary
III. Proposed solution fo further avoiding of clock bugsIt would be useful to calculate the clock settings at compile time and provide compile time asserts if values are not matching. My suggestion would be use of preprocessor (may be tricky) or some python script. What are yours? |
|
@Nukersson Thanks for your feedback. Looks like you are facing the same issue as I showing that reducing the PLL output clock allows the system to boot the sample correctly. I suggest you try the fixing PR #27213 version to see if it solves this issue. I agree on having more clock setting asserts. Most of them should be doable by preprocessor, but we won't get as much information as what STM32CubeMX is able to give us. You are basically proposing to recreate the CubeMX clock assertion system in Zephyr. We could do some basic checks and redirect the user to STM32CubeMX for specific clock tree configurations. |
|
Initial implementation of the clock_control for H7 series (prior to #26980) was setting the APBx dividers BEFORE setting the PLL as SYSCLK which prevented the clocks to go above specification once SYSCLK was set to PLL. This explains why @Nukersson had a working clock tree working prior to #26980 . That is all my mistake. I have changed in #26980 where the PLL is set as SYSCLK source prior to setting the correct APBx buses. This should be OK in #27213 where I preselect dividers for the APBx buses preventing going over the limits. |
|
I have also faced some problems related with the latest patch for clock settings. static int32_t get_vco_input_range(uint32_t pllsrc_clock, uint32_t divm)
{
const uint32_t input_freq = pllsrc_clock/divm;
__ASSERT(input_freq < 1000000UL || input_freq > 16000000UL,
"PLL1 VCO frequency input range out of range");
... |
Thanks for your comment, Could you be more precise about what's wrong with this assertion ? PLL input range is [1MHz;16MHz], so everything below 1MHz or above 16MHz is not a valid input. |
#define __ASSERT(test, fmt, ...) \
do { \
if (!(test)) { \
__ASSERT_LOC(test); \
__ASSERT_MSG_INFO(fmt, ##__VA_ARGS__); \
__ASSERT_POST_ACTION(); \
} \
} while (false)we should assert that we are inside the required range so I think |
You are absolutely right, that's me not knowing how to use assertions 🙃 There also is another assertion: vco_input_range = get_vco_input_range(
pllsrc_clock,
CONFIG_CLOCK_STM32_PLL_M_DIVISOR);
__ASSERT(vco_input_range == -ERANGE, "PLL VCO input frequency out of range. Should be from 1 to 16 MHz");that should be changed to: __ASSERT(vco_input_range != -ERANGE, "PLL VCO input frequency out of range. Should be from 1 to 16 MHz");I will try to embed this correction in #27213 |
@Nukersson Your idea is great and I am trying to implement it using only preprocessor errors. I'm almost done with them and I'll try to provide this detection to #27213 once it is done. I'm just facing preprocessor errors due to: Which prevents the preprocessor from doing any comparison from these defines (break with There are no problems with HSE_VALUE as it is redefined by the build system as @erwango told me. |
Fixes zephyrproject-rtos#27212 by setting the AHB/APBx dividers prior to configuring the PLL as clock source. Prevents going over the limits of APBx clocks when choosing the PLL as system clock source for high frequencies (close to 480MHz) Signed-off-by: Jeremy LOCHE <lochejeremy@gmail.com>
Fixes #27212 by setting the AHB/APBx dividers prior to configuring the PLL as clock source. Prevents going over the limits of APBx clocks when choosing the PLL as system clock source for high frequencies (close to 480MHz) Signed-off-by: Jeremy LOCHE <lochejeremy@gmail.com>
Describe the bug
It is not possible to configure a system clock higher than 400MHz on nucleo_h743zi board. It can also be the case for other H7 boards.
To achieve 400MHz+ frequencies, you need to use the PLL and set the Kconfig PLL parameters for the clock_control driver.
Moreover OpenOCD fails to complete flashing the device with status 1 and hello world is not shown in the console. In order to flash the device with other clock settings, it is necessary to spam the reset button while calling
west flashto connect to the MCU under reset. See why this could happens below.Fixing PR: #27213
To Reproduce
Steps to reproduce the behavior:
Comment existing settings and override them with:
or
or
Expected behavior
Board should be flashed without any issues, Hello World should appear in the console and system clock should be set to 480MHz.
Impact
Prevents the user from setting whatever clock setting he wants.
Could also break some h7 board like mentionned in #26980 .
Logs and console output
OpenOCD crash output:
Environment (please complete the following information):
Why this bug and Partial fix
This bug occurs because some of the APB clocks can exceed the maximum allowed frequencies when PLL is being set as system source clock. In fact, the PLL dividers should be set to maximum prior to setting the PLL as system clock source and then correctly configured to prevent the frequencies to go out of the limits.
About OpenOCD not being able to complete:
That must be due to the clock tree being stuck in an unspecified state preventing OpenOCD to complete all of its commands and exit with
shutdown command invoked. Because the flash writing operation succeeds in the first place the MCU must have booted the wrong clock configuration and frozen some of its clock buses (APBx for instance) preventing OpenOCD to send commands likereset haltorreset run.I have a fix that allows the clock config from HSI/CSI/HSE + PLL to be flashed and used at 480MHz without any problems on nucleo_h743zi.
Additional context
This problem appear for @Nukersson on his nucleo_h745zi_q board when trying to test #27188 .
The text was updated successfully, but these errors were encountered: