STM32U0 timer clocks x2

[Hans_W]

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.

[Sarra.S]

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."

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

[Hans_W]

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.

[Sarra.S]

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! 

[Sarra.S]

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: 

Hope this is clearer! 

[Bubbles · Accepted solution]

Hi @Hans_W ,

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

The RM needs some more correction.

Thanks a lot for reporting this problem.

BR,

J

[Hans_W]

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?

[Bubbles]

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

[Bubbles]

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

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.