search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.08k stars 6.19k forks source link

stm32f3: clock control should be able to represent USART1 clock erratum #53317

Open tagunil opened 1 year ago

tagunil commented 1 year ago

Is your enhancement proposal related to a problem? Please describe. Some STM32F3 devices have a bug in USART1 clocking. ES0246 describes it like that:

USART1 is mapped on the fast APB (APB2) and its clock can be selected among four different sources using the USART1SW [1:0] bits in the RCC_CFGR3 register. The default configuration selects PCLK1 (APB1 clock) as USART1 clock source instead of PCLK2 (APB2 clock).

This problem leads to wrong baud rate calculation, because PCLK1 and PCLK2 frequencies are usually different.

Describe the solution you'd like I'd like to have a way to pass a specific PCLKx as the domain clock source for the peripheral instead of the generic STM32_SRC_PCLK which cannot be used for baud rate calculation anyway.

Describe alternatives you've considered An alternative would be to include device-specific hacks to USART driver, but I don't think it's a good idea. Another alternative would be to set SYSCLK as the default domain clock source, but that violates "Note 2" rule from st,stm32-rcc.yaml.

Additional context Affected devices are STM32F30xx6/8, STM32F334x4/6/8, maybe some others. Looks like B/C/D/E devices are not affected. There are several application-specific workarounds possible, but I'd like to see the default solution, because the issue affects several in-tree boards.

tagunil commented 1 year ago

@erwango Could you please look at that as you are the one who implemented domain clocks? I'm thinking about introducing H7-like STM32_SRC_PCLKx aliases for STM32_CLOCK_BUS_APBx, but I'm not sure about that.

erwango commented 1 year ago

Another alternative would be to set SYSCLK as the default domain clock source, but that violates "Note 2" rule from st,stm32-rcc.yaml.

@tagunil This is what was done recently for I2C, that have similar issue: https://github.com/zephyrproject-rtos/zephyr/pull/53216/commits/fa428afeead70a2bc185dca2ae128ef47a1d68f7

I might need to edit note 2 and state "when possible" or "unless default reset configuration doesn't allow to provide a functional configuration"

zephyrbot commented 4 months ago

Hi @erwango,

This issue, marked as an Enhancement, was opened a while ago and did not get any traction. Please confirm the issue is correctly assigned and re-assign it otherwise.

Please take a moment to review if the issue is still relevant to the project. If it is, please provide feedback and direction on how to move forward. If it is not, has already been addressed, is a duplicate, or is no longer relevant, please close it with a short comment explaining the reason.

@tagunil you are also encouraged to help moving this issue forward by providing additional information and confirming this request/issue is still relevant to you.

Thanks!