Skip to main content
Visitor II
February 17, 2025
Solved

STM32U0 timer clocks x2

  • February 17, 2025
  • 8 replies
  • 2175 views

In contrast to the STM32L0 that I am migrating from to the newer STM32U083, the U0 clock tree (Reference manual RM0503 V2.0 figure 11) does NOT show that timer clocks are PCLK*2 when APB prescaler>1.

Also, it states in 5.2.14 that timer clock TIMPCLK is equal to PCLK. In other STM32 series like F1, L4 and L0 I was used to have timer clock doubling when PCLK<HCLK. A feature I always disliked, because it requires reconfiguring timers when you want to throttle the CPU speed.

However:

  • The HAL (STM32Cube_FW_U0_V1.2.0) function HAL_RCCEx_GetPeriphCLKFreq() returns 2x PCLK, but only for TIM15 and TIM1 in that case (APB prescaler>1). This exception for TIM1 and TIM15 is nowhere to be found in the reference manual.
  • When I configure TIM6 to clock from 8MHz PCLK (1/2 of my 16MHz HCLK) with prescaler 8 (PSC register value 7) it appears to run twice as fast as expected: 2MHz instead of the expected 1MHz. Apparently it is clocked bt 16MHz (2*PCLK). 
    (in contrast, my UARTs run at the expected 8MHz clock, as the baud rates are correct)

Can someone tell me (and afterwards upate the Reference Manual of STM32U0) for which timers the PCLK is doubled (like in other STM32 series) when the APB prescaler is larger than 1? Or is this a silicon bug and wasn't this supposed to happen?

Maybe the firmware library (hal_rcc/hal_rcc_ex) needs an update as well, if the U0 behaves like L0/L4/F1 in this case.

 

    This topic has been closed for replies.
    Best answer by Bubbles

    Hi @Hans_W ,

    here is screenshot from the STM32CubeMX utility, where the clock tree is more accurate:

    Screenshot 2025-02-18 152154.png

    The RM needs some more correction.

    Thanks a lot for reporting this problem.

    BR,

    J

    8 replies

    ST Employee
    February 17, 2025

    Hello @Hans_W

    >>This exception for TIM1 and TIM15 is nowhere to be found in the reference manual.

     the exception is described in the paragraph that you've mentioned: 

    "The timer clock TIMPCLK is equal to the PCLK frequency.
    For TIM1 and TIM15, PLLQCLK clock can also be selected, if:
    • PCLK is derived from PLLRCLK, and
    • PLLQCLK frequency is an integer multiplication by 2 or more of the PCLK frequency,
    without exceeding 56 MHz."

     

    SarraS_0-1739809192935.png

    I'm further investigating this, I will keep you updated!

     

    Hans_WAuthor
    Visitor II
    February 18, 2025

    Hi Sara,

     

    I'm only referring to PCLK selected as timer clock. This issue is not about other clock sources like PLL. Nowhere is stated that this PCLK is multiplied by 2 when PCLK<HCLK before being fed to the timers.

    With TIM6 I experienced this doubling happening (HCLK 16Mhz, PCLK 8MHz, TIM6 running at 16MHz).

    The firmware library function HAL_RCCEx_GetPeriphCLKFreq() that can return current clock speed for TIM1, TIM15 and LPTIM timers returns PCLK*2 for TIM1/TIM15 but PCLK for LPTIMx. I haven't tested any of those timers, but I expect that this multiplication occurs for all timers running from PCLK.

    ST Employee
    February 18, 2025

    Hello @Hans_W

    I can confirm that this needs a clarification (either from RM side or from the HAL library side), I have escalated this to the dedicated team (Internal ticket number: 203488). 

    I will keep you updated! 

    ST Employee
    February 18, 2025

    Hello again @Hans_W

    The RM needs to be updated (tracked internally), when the PCLK is too low the TIMPCLK is set higher as shown in the STM32CubeMX screenshot: 

    SarraS_4-1739889199333.png

    Hope this is clearer! 

    BubblesAnswer
    ST Employee
    February 18, 2025

    Hi @Hans_W ,

    here is screenshot from the STM32CubeMX utility, where the clock tree is more accurate:

    Screenshot 2025-02-18 152154.png

    The RM needs some more correction.

    Thanks a lot for reporting this problem.

    BR,

    J

    Hans_WAuthor
    Visitor II
    February 18, 2025

    Hi Bubbles,

    It is clear that the RM needs updating in terms of TPCLK.

    Can you specify which timers run on TPCLK and which on PCLK?

    Because in CubeMX clock configuration, only TIM1, TIM15 and the LPTIMx are visible. Notably: according to CubeMX (latest 6.13), the TPCLK does NOT apply to the LPTIMx timers.

    Scenario in CubeMX for STM32U083RCT6:
    HCLK=SYSCLK = HSI-RC=16MHz
    PCLK=HCLK/2 = 8MHz
    TPCLK to TIM1/TIM15= PCLK*2 = 16MHz
    but LPTIMx are fed with 8MHz PCLK, not TPCLK.

    Can you confirm that the LPTIM1..3 are the exception and are all other timers that use peripheral clock are connected to TPCLK as suggested by CubeMX in the picture below?

     

    Hans_W_1-1739892378657.png

     

    ST Employee
    February 18, 2025

    Hi @Hans_W,

    sorry, I may have misled you.

    I'll test the timer frequency tomorrow and let you know what's the actual situation.

    BR,

    J

    ST Employee
    February 19, 2025

    Hi @Hans_W,

    there was some miscommunication internally on the topic, but finally the RCC design lead confirmed the CubeMX displays the TIMPCLK branch correctly.

    So my initial answer stands,

    J

    Hans_WAuthor
    Visitor II
    February 19, 2025

    Hi Bubbles, 

    I didn't doubt CubeMX's TPCLK branch and I certainly don't feel mislead, but the diagram doesn't explicitly cover all existing timers and the LPTIMx timers seem not to use TPCLK but PCLK instead.

    So, did this RCC design lead confirm my guess that all timers not explicitly visible in the CubeMX clock overview are clocked by TPCLK and that the LPTIMx timers are the exception because they use PCLK instead (never doubled frequency)?

    Then I can be sure which timer is clocked from PCLK and which from TPCLK.

    ST Employee
    February 19, 2025

    Hi @Hans_W ,

    no it's only TIM1 and TIM15 that use the TIMPCLK. Another way to look at the timer clock options is to see the RCC_CCIPR settings. It lists all the options available and their values.

    The TIMPCLK is inherited from STM32G0, where the multiplier was a trick to overclock the timer to reach 128MHz - great for PWM. But that was not efficient enough for the ultra low power U0 and the option for x2 clock was to be removed. A miscommunication led the design to only remove the multiplier from the undivided clock, while the RM master original intention was to remove it completely.

    BR,

    J

    Hans_WAuthor
    Visitor II
    February 20, 2025

    To resume:

    • clock tree (Fig 11) should be corrected to include the x2 step in case PCLK PRESC >1
    • 5.2.14 should be clarified that TIMPCLK is 2x PCLK frequency if PCLK PRESC >1 and that it is fed to all TIMx, but not to LPTIMx.
    ST Employee
    February 21, 2025

    @Hans_W ,

    yes, that's the change we need to do in the next RM revision. But we won't use the exact phrase "all but LPTIM". I'd rather be specific and say it's for TIM1 and TIM15.

    BR,

    J

    Hans_WAuthor
    Visitor II
    February 21, 2025

    Hi Bubbles,

    Please look again, it is not limited to TIM1/TIM15, TIMPCLK is fed to all TIMx, including TIM2/3/6/7/16, see the yellow highlighting in my picture above. Make sure the point where the "X2" is performed is on the right spot in the signal lines.

    Otherwise TIM6 would never have been running at the double PCLK frequency, as observed. 

     

    If you look at the CubeMX clock diagram you see the same TIMPCLK signal, slightly renamed to TPCLK, being fed to TIM1/TIM15 but also being output as "APB Timer Clocks" (my post of Feb 18).

    So you can phrase it in 5.2.14 as "TIMPCLK is used for all TIMx timers. The LPTIMx timers use regular PCLK when selecting the peripheral clock"

    Super User
    February 21, 2025

    If it's exactly the same scheme as in 'L0 - and it appears to be so from the conversation above - why don't you just use the same phrasing and same depiction as in 'L0 RMs?

    JW

    Hans_WAuthor
    Visitor II
    February 21, 2025

    You're almost right: TIMx and LPTIMx clocking seems identical to L0, but STM32U0 also has TIM1/TIM15 with the additional PLLQCLK option. The only thing missing is the "X2" step in the clock tree and in 5.2.14. The L0 RM doesn't have that paragraph.