2024-07-22 11:52 AM
I am working on a project that uses STM32F103 and STM32G4 as MCUs. They need to communicate between each other using UART. I am trying to configure STM32F103 UART clocks to match the STM32G4's clocks but I have not been able to figure out where to do that. I found a document that says UART clock is based on HCLK, but is there any prescaler that configures the UART clocks? If not, what is the frequency the UART clocks are based in so I can match it by configuring the STM32G4s clock, instead.
To be more specific, I am using all ports as asynchronous. USART1, USART2, USART3, UART4, and UART5.
Solved! Go to Solution.
2024-07-23 02:30 PM - edited 2024-07-23 02:31 PM
@IvanOrot wrote:I am trying to configure STM32F103 UART clocks to match the STM32G4's clocks
Why?
There is absolutely no need to do that!
You don't fiddle with your PC's clock to have it communicate over UART, do you?!
All that matters is that the baud rates match.
(and, as @Pavel A. said, the STM32G4 can even do automatic baudrate detection)
2024-07-22 12:06 PM
Everything is fully described in the Reference Manuals for your stm32s. They will be different because the G4 are much more modern and so have many more capabilities than the F1. So you will have to study both of them to understand what is going on.
Because the RM is complete, it is complicated and hard to get your head around first time. So ST produce their "Cube" tools that hide the complexity and possibly limit your choices. But I find them inadequately documented and stick with RM where I can.
In general, a UART will use a fractional-n divider to generate a baud-rate-clock from the incoming clock (which may be a PCLK - either PCLK1 or PCLK2 depending which UART) or HCLK or SysClk. I expect G4 to also support clocks directly from the HSI/HSE oscillator so that the baud-rate does not need to be recalculated should you change the CPU speed on-the-fly to save power when there isn't much processing to do.
The output from the baud-rate-clock needs to be 16 times the actual baud-rate, so that the UART may sample the input three times in the centre of the bit-period to reduce noise-susceptibility while giving tolerance to baud-rate errors. (There are sometimes options to work at 8 times as well where you want high baud-rates in relation to the baud clock).
2024-07-22 06:37 PM
Start a project in CubeMX and look at the Clock Configuration tab to understand the various clocking options. It's in the RM as well, but is faster to get to and understand in CubeMX.
2024-07-23 11:31 AM
I did. I guess I am not understanding what configuration option controls the UART/USART clocks. When using STM32G4 I was able to use CubeMx to set the USART/UART clocks at different frequencies. For now, I am setting all clocks to 16MHz, but with STM32F103 I am not able locate where to adjust the USART/UART clocks to match the 16MHz. I guess I can use my oscilloscope and play around with the configurations but it would save me a lot of time to understand what is happening.
2024-07-23 12:14 PM
USARTs of STM32G4 have auto baudrate detection capability. This means that STM32G4 can tune its USART to the actual baudrate of the other side, even "non-standard". The detection can be repeated as needed. This solves your issue.
2024-07-23 02:04 PM
On the STM32F103, the clock feeding USART is either PCLK1 or PCLK2 depending on where the peripheral is. There is no option to change it to anything else.
2024-07-23 02:30 PM - edited 2024-07-23 02:31 PM
@IvanOrot wrote:I am trying to configure STM32F103 UART clocks to match the STM32G4's clocks
Why?
There is absolutely no need to do that!
You don't fiddle with your PC's clock to have it communicate over UART, do you?!
All that matters is that the baud rates match.
(and, as @Pavel A. said, the STM32G4 can even do automatic baudrate detection)
2024-12-06 12:35 PM
BTW you were right.
I thought the baud rate was based on the defined timer, like bit per second or something. I guess I should have paid more attention in class. Baud rate is symbol per second, so if I define the baud rate 115200 for all UART ports and everything was be fine.
Thank you.
2024-12-06 12:39 PM
I meant i thought baud rate was bits per cycle, and since cycles were shorter/faster when the timer was oscillating faster, the data transfer speed wouldn't match up. NVM i'm confusing myself trying to explain why I was confused haha. The point is you were right.