STM32F030 clock control: software timers depend on special clock settings

[danielSchaeble]

A simple project with just one software timer and LED feedback was used. The used MCU is the STM32F030C8T6R. The timers depend to the rcc and/or pll frequencies, which actually should independent. The following configuration lead to working software timers.

By changing the frequency of the rcc or using the pll with a separate and valid configuration the timers do take more or less time than expected. The clock settings were checked with the clock tree of CubeMX.

Tested on: Ubuntu 20.04.5 LTS Zephyr 3.2

Related to discord post: https://discord.com/channels/720317445772017664/969266602925252638/1075368071713259531

[erwango]

@danielSchaeble An example of configuration leading to PWM issue ?

[danielSchaeble]

The pwm does also work with the clock settings above, but it is also mandatory to specifiy the st, prescaler. If left out the pwm does not work at all. The pwm is used for the RGB LEDS.

The actual problem is also the dependency to the rcc/pll configuration and the mandatory st,prescaler. (The st,prescaler was not mandatory with stm32wl MCU.)

[erwango]

it is also mandatory to specifiy the st, prescaler. If left out the pwm does not work at all. [...] The st,prescaler was not mandatory with stm32wl MCU.

When not specified, st,prescaler is set to default value (0). Depending on RCC configuration (which might differ on your WL target), st,prescaler might require tuning, this is expected.

The timers depend to the rcc and/or pll frequencies, which actually should independent.

Timer clock freq depend on APB domain frequency (equal if APB =1, 2xAPB Freq otherwise). This is handled internally in PWM driver. So to me this is normal, unless there is a valid configuration which isn't working

[danielSchaeble]

When not specified, st,prescaler is set to default value (0). Depending on RCC configuration (which might differ on your WL target), st,prescaler might require tuning, this is expected.

What does it mean to set the prescaler to 0? Isn't it a multiplicator/divider and setting it to 0 would set the frequency to 0? All clock prescalers, also in the WL target project, were set to default project settings of a CubeMX project, so it should be valid.

Timer clock freq depend on APB domain frequency (equal if APB =1, 2xAPB Freq otherwise). This is handled internally in PWM driver. So to me this is normal, unless there is a valid configuration which isn't working.

So does this mean it is normal that there is only one valid rcc/pll setting to make all zephyr timers and pwm work? Of course only considering valid clock settings in terms of it is valid for the target in general.

[erwango]

What does it mean to set the prescaler to 0? Isn't it a multiplicator/divider and setting it to 0 would set the frequency to 0? All clock prescalers, also in the WL target project, were set to default project settings of a CubeMX project, so it should be valid.

See bindings doc dts/bindings/timer/st,stm32-timers.yaml:

  st,prescaler:
    type: int
    required: true
    description: |
      Clock prescaler at the input of the timer
      Could be in range [0 .. 0xFFFF] for STM32 General Purpose Timers (CLK/(prescaler+1) )

it is normal that there is only one valid rcc/pll setting to make all zephyr timers and pwm work?

You should be able to get PWM working with every valid RCC/PLL configuration ... BUT it might require to tune st-prescaler

[danielSchaeble]

Okay then this seems to be normal. Does that also apply to zephyr timers? Is it correct that a timer can take less time than specified, when a prescaler is not set with a valid clock configuration?

[erwango]

Okay then this seems to be normal. Does that also apply to zephyr timers? Is it correct that a timer can take less time than specified, when a prescaler is not set with a valid clock configuration?

Yes, it will be the same if you're using counter_ll_stm32_timer (same IP, similar driver).

[danielSchaeble]

Okay thanks, then this is not a bug.