Basic rules for the clock tree? Topic is solved

ChibiOS public support forum for topics related to the STMicroelectronics STM32 family of micro-controllers.

Moderators: RoccoMarco, barthess

TKorho
Posts: 18
Joined: Mon Sep 13, 2021 6:46 pm
Has thanked: 2 times
Been thanked: 1 time

Basic rules for the clock tree?

Postby TKorho » Wed Feb 02, 2022 11:09 pm

I have created some new board files to ST_STM32H747XI_DISCOVERY.
This was discussed a bit in an another thread. Not strictly relevant.

I had to borrow and modify some board files, and create some of my own, I am not confident with the mcuconf.h clock tree. I know it is a delicated subject and I don't expect to learn everything from a forum post.

I do have the STM32CubeMX tool in use, and I can calculate the new values. The ChibiOS variables in the mcuconf.h are quite clear referenced to the ST clock tree map. Now that I understand the MPU timing is based on the clock tree spanning in mcuconf.h, and the clock tree can be calculated with the CubeMX, I have progressed quite a lot.
( My current challenge is the one third-speed chThdSleep. This must be bound to mcuconf.h defined STM32_ST_USE_TIMER (2) and the clock tree for this timer. Main clock, and the perihperhal APB are the same... But this is my personal problem, I'd rather ask here about more generic clock tree spanning. )

Are there some basic rules for the (for eg STM32 M7) clock tree, and what does it require or depend on? At least are there any "must do"s?

There does not seem to be a simple skeleton clock tree for an MPU as complex as M7/H7, but one may need to fine tune the clock tree per project or per use case basis. With the F411RE I was able to get the basic setup, and it worked for any use. I didn't see a need to change anything with the clocks.

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: Basic rules for the clock tree?  Topic is solved

Postby Giovanni » Thu Feb 03, 2022 7:24 am

Hi,

H7 is a complex beast, your best friend is the RCC section in the Reference Manual, importing parameters from ST's Cube tool is usually a safe approach.

Note that the clock tree code is well guarded by preprocessor checks, if some parameter is wrong or if some clock goes out of spec you get errors at compile time.

About timers, their prescalers are programmed starting from clocks defined in the clock tree, usually there is nothing to do there, of course you need to make sure that the required output frequency is obtainable using the 16 bits timer prescaler.

Giovanni

TKorho
Posts: 18
Joined: Mon Sep 13, 2021 6:46 pm
Has thanked: 2 times
Been thanked: 1 time

Re: Basic rules for the clock tree?

Postby TKorho » Thu Feb 03, 2022 8:23 am

Acknowledged. Thank you.
I have proofed the clocks both by CubeMX and all the ChibiOS checks and asserts. So I probably can expect those to at least run.

I'll try to find out the particularities per peripheral and with the Reference Manual when I run into them. I'll need to go peripherals one by one, when I run into them. (This was with the unsupported H747-DISCO.)
The chThdSleepMilliseconds is wrong interval now, measuring three times the nominal. (1000ms takes 3 seconds. 200MHz sysclock and APB1&2, HSE 25MHz). And SERIAL USART1 prints garbage, but that must be something with the integrated ST-Link V3 and pin configuration.

TKorho
Posts: 18
Joined: Mon Sep 13, 2021 6:46 pm
Has thanked: 2 times
Been thanked: 1 time

Re: Basic rules for the clock tree?

Postby TKorho » Fri Feb 04, 2022 12:51 pm

While I thought this discussion is over, and better just read the Reference Manual, I have found some things that would need clarification. If possible.

  1. When I try to use chThdSleepMilliseconds(#), it is somewhat off. In fact it has varied a lot based on the clock tree settings, but I have not been able put my finger on the direct dependency. I thought chThd would calculate the frequency automatically. What clocks, expectations or dependencies does the ThdSleep, or the MS2I macros rely on? I know which timer is ST, and I know the timer APB# clock rate. But the millisecond-value does not match the actual output, nor I cannot deduct the dependency based on the off-factor. For eg if I have blinker toggle with 1000ms delay (2s cycle), the measured full cycle is 0,798s. Does the chThdSleep assume some specific reference clock value? Or does the value need to be injected somehow? Board.h has the HSE value, and it is correct.
  2. When using PWM or GPT, the TIM frequency, period and duty cycle concepts are rather understandable. But my output frequencies do not match. I have to calculate and set PWMD->tim->PSC and fine tune CCR period. I thought the implementation would calculate those automatically based on the PWMConfig. Is there any automatization in timer setup functions? Are there intentions to have?
  3. If using advanced timer modes, like asymmetric PWM, and there is no direct support on the API: is it ok to modify the TIM register along with the API functions? Is it even possible to use "non-API supported modes"? Any known complications?

Thanks, and sorry. One fool can ask more questions than 10 wise men can answer... :oops:

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: Basic rules for the clock tree?

Postby Giovanni » Fri Feb 04, 2022 2:04 pm

Hi,

The system tick is calculated in the "ST" driver and input frequencies are those coming out of the clock tree module. The result is accurate as long the selected frequency can be generated by the HW timer AND clock settings are correct in board.h and mcuconf.h.

All demos on all platforms rely on this, there must be something in your setup.

Conversion macros approximate intervals in excess, so if you ask for 15500uS interval and your systick is 1000hz then you will get a 16mS interval. Macros can also fail because integer overflow issues, use conversion functions instead chTimeXXX().

Giovanni

TKorho
Posts: 18
Joined: Mon Sep 13, 2021 6:46 pm
Has thanked: 2 times
Been thanked: 1 time

Re: Basic rules for the clock tree?

Postby TKorho » Sat Feb 05, 2022 9:26 am

Victory!
The problem has been solved. It was due to too small ST frequency, compared to ridiculously fast MPU! And limited ST TIM resolution. But with 400MHz 1000Hz ST can cause overflow even with 32bit timer.

At first I noticed the solution when I was playing with some smaller frequencies for the H7 system clock. When I noticed the timing does hit correct at times, I started testing with ST ticks size. I had some old example from much smaller MPUs, and didn't think I need very tight ST timing!
For some reason this also solved the corrupted SERIAL VCP to ST-Link: I had not suspected the ST at all, since I expected the serial to be quite slow for the MPU.

For anyone else having problems with incorrect timing and Clock Tree: the STM32CubeMX clock timer tool is very very good to calculate the values. And since ChibiOS uses the (almost) same register names, it is relatively easy to copy the values from CubeMX even by hand. And when you do the mcuconf.h clock tree a few times yourself, it becomes quite easy to change the values and build totally your own clocks.
In my case I need quite fast PWM timers, thus APB1 timer clock is the important one, and I didn't bother to slow down the SysClock for that... Thus my ST frequency is rather 1M than 1kHz.


Return to “STM32 Support”

Who is online

Users browsing this forum: No registered users and 16 guests