cancel
Showing results for 
Search instead for 
Did you mean: 

STM32G431 tim_ker_ck, tim_pclk source

DMeie.2
Senior

I'm looking into calculating the timings for the brk filters for the TIM1 periphery. Mentioned there is the "tim_ker_ck" and the "tim_pclk" respectively.
I cannot seem to find any information on where these come from.

The clock tree in the RM says that TIM1 is connected to the APB2 using PCLK2, however there's nothing on how PCLK2 translates to tim_ker_ck or tim_pclk.

1 ACCEPTED SOLUTION

Accepted Solutions
CMYL
ST Employee

Hello @TDK 

Thank you well seen, this is confusing ☹️ 

It needs to be clarified as well !!!

tim_pclk = PCLKx, the clock ratio can be  1,2,4,8 and 16 of the AHB clock source HCLK.

tim_ker_clock is derived from the PCLKx=tim_pclk source, it is always 1x or 2x of tim_pclk. 

CMYL_0-1708770606481.png

Note that this scheme is SoC dependent, it applies to STM32G4x1 (STM32G4x1 Access line: general-purpose microcontrollers with an entry level set of analog peripherals - STMicroelectronics), the first question is about STM32G431. I agree with @waclawek.jan,  it is subject of integration and internal design spec, the scheme is not the same between all the part numbers.  

Best Regards,

Younes

 

View solution in original post

10 REPLIES 10
TDK
Guru

tim_pclk tim_ker_ck is either 1x the APB clock if the APB prescaler is /1, else it's 2x the APB clock.

TDK_0-1708696454111.png

 

If you feel a post has answered your question, please click "Accept as Solution".
CMYL
ST Employee

Hello @DMeie.2,

tim_pclk is the clock used for interfacing the Timer registers (it is always PCLK2) and tim_ker_ck is the one used for internal timer counters (here PCLK2 x1 or x2). I agree documentation needs to clarify this difference in the RM0440.

  • I will submit an update to clearly differentiate between both clock inputs.  

Below we are talking about the tim_ker_ck, as mentioned by @TDK, it is either PCLK2 x1 or PCLK2 x2:

  • the kernel timer clock frequencies are automatically defined by hardware. If the APB prescaler equals 1, the kernel timer clock frequencies are set to the same frequency of the APB domain, otherwise, they are set to twice (×2) the frequency of the APB domain ( see RM0440, section 7.2.13 Timer clock).
  • RM0440, Figure 17. Clock tree, shows the tim_ker_ck

CMYL_1-1708729580825.png

Best regards,

Younes

 

@CMYL Thanks for clearing that up. I'm wrong above then, and I'll edit it.

If it's the case that tim_ker_ck is always 1x or 2x of tim_pclk, why does the RM say the ratio must be between 1 and 16? It's always either 1 or 2, right?

TDK_0-1708749795724.png

 

If you feel a post has answered your question, please click "Accept as Solution".

This probably is a remnant from the internal design document and a requirement for the "integration" of timers into the clock/bus fabric when designing the chips (in effect it says, that you have to derive PCLK (i.e. the entire APB bus clock) by dividing tim_ker_ck (of course there's no APB multiplier, that's just a description which is supposedly simpler to grasp (not to me btw.))). There are STM32 models where the ratio is not only 1:1 or 1:2.

As it's only in one of the 3 chapter, it at the same time also shows how bad idea it is to split the timer section into three or four, rather than to try to keep it consistent by having a single chapter and a simple table of features for the variants (and maybe a set of footnotes in the registers' description to note which bit is present/absent in which variant), as is usual in other modules (e.g. UART/USART - although that in turn is itself an extremely bad choice of naming made even worse by propagating it into the "libraries" and, what's worse, into the CMSIS-mandated device headers).

JW

CMYL
ST Employee

Hello @TDK 

Thank you well seen, this is confusing ☹️ 

It needs to be clarified as well !!!

tim_pclk = PCLKx, the clock ratio can be  1,2,4,8 and 16 of the AHB clock source HCLK.

tim_ker_clock is derived from the PCLKx=tim_pclk source, it is always 1x or 2x of tim_pclk. 

CMYL_0-1708770606481.png

Note that this scheme is SoC dependent, it applies to STM32G4x1 (STM32G4x1 Access line: general-purpose microcontrollers with an entry level set of analog peripherals - STMicroelectronics), the first question is about STM32G431. I agree with @waclawek.jan,  it is subject of integration and internal design spec, the scheme is not the same between all the part numbers.  

Best Regards,

Younes

 

Hello @waclawek.jan

In response to your question about splitting Timers documentation into 3/4 chapters ...

Actually, I will share your suggestion to centralize into one chapter  "basic, advanced, legacy, high resolution timers" ... But in my opinion it difficult to compile all in one chapter as for UART/USART ... one reason is that there are 4 different designs/peripherals, Basic, Advanced, GP and high-res. The 3 first one can be easily merged into one chapter, but not with high-res timers in terms of the registers sets and naming. Other reason is the generic integration parameters which are different, signals for example are widely different as you can see it in the block diagrams. Besides SoC integration description such as (clock, power domains ....) or mapping (addresses/busses) are not easy at all. One more reason, one chapter will be very long .... if not compiled correctly will be error prone !!! 

Add to all of that, our customers are familiar with this RM presentation ... I'm afraid what could be their reaction if merged together, but with some confusing/erroneous description .... the business is in question here 😁  

To be constructive, what can be done easily is to add one table in each chapter that summarizes the implementation features of all timers as one for USART/UART/LPUART.

CMYL_0-1708774240586.png

However, I didn't catch you point  (e.g. UART/USART - although that in turn is itself an extremely bad choice of naming made even worse by propagating it into the "libraries" and, what's worse, into the CMSIS-mandated device headers).  

Can you explain ? give explicit examples ... it could be matter of enhancement for our firmware !!!

Best Regards,

Younes

 

Hi Younes,

> there are 4 different designs/peripherals, Basic, Advanced, GP and high-res

If you count HRTIM, then there are 5: LPTIM, too. But HRTIM and LPTIM are very different and they should be kept separately; there's no doubt about that.

OTOH, there are not 3 remaining types, as there are substantial differences between TIM15..17 and either TIM1/8/20 or TIM2..5. While some materials (e.g. RMs) call TIM15..17 General Purpose, but unlike TIM2..5 which are supposed to be the quintessential General Purpose (yet still exhibiting the 16-bit/32-bit difference which IMO is still quite significant), they don't have complementary outputs as TIM15..17 do, necessitating in the latter to use TIMx_BDTR features to enable outputs, which is IMO a significant difference. AN4013 has 6 to 8 cathegories of timers (depending on how you count them, exactly), excluding HRTIM and LPTIM.

So, why are there 3 or 4 "pure"-TIM chapters in the RMs, not 6 or 8? The division is arbitrary/historical. Look at the TIM15..17 chapters, they itself display 2 different designs, with duplicated registers subchapter.

Similarly for TIM9..14, which again called General Purpose in RM, lack many of features of TIM2..4, rightly have a separate chapter; but then, again, they themselves are of two different variants slammed into the same chapter.

> One more reason, one chapter will be very long .... if not compiled correctly will be error prone !!!

Certainly. But maintaining 3-4 chapters is not less error prone - this very thread is the proof (and there are many similar differences between the chapters which accumulated during time just because some of them have been updated and others not).

> Add to all of that, our customers are familiar with this RM presentation ...

Yes, this is a very valid point. Yes, some bad decisions cannot be un-done effectively. At this point of time, you may be right and the change may not be worth it.

> To be constructive, what can be done easily is to add one table in each chapter that summarizes the implementation features of all timers

That may be a good idea. Partially it is in AN4013, but it needs to be made mode/subfamily-specific, and needs to be expanded to minute details (e.g. listing registers/bitfields present/absent in individual variants). But I warn you: to do it properly, and to make it useful, it is again a *not easy* task (in fact, what's an *easy* task when it comes to *proper* documentation?)

---

UART vs. USART, I've written about it here.

JW

@CMYL 

Hi, I am stuck with the same question. Unfortunately your answer does not clear up the mystery. Your writing 'always' suggests this cannot be changed (i.e. there is no flag in a register somewhere that I can change) is this correct?. At least that would explain why I can't find anything of the sort. If so, it should be possible to clearly state what that value  is, 1x or 2x. Why does the manual then not clearly state what that value is, instead of confusing people with such a vague statement?

I can of course try it out, then I know (as soon as I actually get the timer to work). Still that would make it the least satisfying answer to a technical issue that I have received in a long time.

> If so, it should be possible to clearly state what that value is, 1x or 2x.

tim_pclk is the APB clock of the APB bus, on which is given timer located (see the block diagram, first figure in Datasheet; or peripheral register boundary addresses table in System and memory overview chapter in RM, usually 2nd chapter)

tim_ker_clk is described as Timer clock in the RCC chapter of RM, e.g. for 'G4:

waclawekjan_0-1712597284745.png

JW