Bug in F3 USARTv2 BRR calculation

[gdelazzari]

Hello, I'm on ChibiOS 18.2.1, STM32F3 (the F303K8 Nucleo-32 to be precise, shouldn't be relevant) and I found out that if I change the STM32_PPRE2 from STM32_PPRE2_DIV2 to STM32_PPRE2_DIV1, USART1 (using the Serial driver) runs at half the baudrate (0.51 times the desired baudrate, to be precise). Shouldn't ChibiOS be calculating correctly all the clocks and setting them appropriately?

Did I found a bug or am I missing something in some configuration header?

Steps to reproduce:
- Take the Nucleo-32 F303K8 demo, clone the project
- In main, init SD1 with whatever baudrate you like (115200 in my case) and init the respective pins (PA0/PA1) to AF7
- Make the code output stuff on SD1
- Run project -> everything is fine, the right baudrate is used (checked with logic analyzer)
- In mcuconf.h, change STM32_PPRE2 from STM32_PPRE2_DIV2 to STM32_PPRE2_DIV1, which should be allowed since that clock domain can run up to 72MHz if I'm not wrong - and, in fact, the compile-time checks have nothing against that).
- Run again without changing anything else -> baudrate is half the one I initialized the Serial driver with. Curiously enough, USART2 connected to the ST-Link doesn't seem to be affected even if it's in the same clock domain. I didn't check with the logic analyzer but the serial terminal, which is set at the baudrate I'm expecting, shows everything correctly. So I guess it's running at the right baud unless there's some "super magic auto baud thing" going on somewhere in some thing, but I highly doubt it based on my experience.

[Giovanni]

Hi,

Moving in "bug reports" for verification.

Giovanni

[gdelazzari]

Thanks, sorry if I wrote here and not directly in the bug reports section, but I wasn't sure if it was my fault or a bug in the HAL module.

[gdelazzari]

I did some investigation, seems like the clocks are being calculated incorrectly indeed.

USART1, as shown in the clock tree at page 128 of the reference manual (ST document RM0316) for the STM32F303x6/8, is the only USART module that has a selectable clock (you can also see that in the table at page 887) while the other ones seem to be connected to the PCLK2 clock domain. USART1 can select between PCLK1, SYSCLK, the HSI and LSE. What's happening in my code, I guess, is that PCLK2 doubles when I change from STM32_PPRE2_DIV2 to STM32_PPRE2_DIV1 (and that is right) but then the Serial driver calculates the BRR value using PCLK2 while it should calculate it with PCLK1 (or whatever other clock is selected). Can you confirm this may be what's happening? I may have a go at patching the issue in the next days if that's the case.

[Giovanni]

bump