STM32L052K8U6 - Now I have a question - How much the internal clock is reliable ? Is that any option to use my external clock for UART 115200 baud rate communication.

[SR.18]

I am planning to use STM32L052K8U6. With this Controller I am planning to use UART and ADC and digital IOs. Only LSE (low speed external clock) is there and I can only provide 32.768KHz. With this clock I can't generate 115K baud rate with LSE alone, that is I need to use Internal clock (checked clock tree).

Now I have a question - How much the internal clock is reliable ? Is that any option to use my external clock for UART 115200 baud rate communication.

[S.Ma]

This is a question of time drift and tolerances.

What is the min max frequency that will be applied to the USART on each device.

Wost case will be max on one side and min on the other side.

Sending 8 bit, the errors will come from sampling the start bit fall edge, until last data or parity bit.

If the skew is tolerable, there should be no problem.

The clock tolerances depends also on temperature range.

115kbps might be most of the time ok, higher baudrate such as 960k may surely fail.

Here you have precise LSE which I think can calibrate HSI.

In other parts like L4 there is MSI which brings good precision at high frequency from LSE.

[Jack Peacock_2]

Clock jitter on async serial lines is a serious problem if you pack your data words close together. Being asynchronous there is some tolerance with clocks but you need to give the UART receiver time to start syncing to a new frame after receiving the old one. That's the process where the receiver samples the incoming stream for the start bit for a frame of data bits.

Of course if the timing is too far off you'll see framing errors and corrupted data no matter what. Only solution is to slow down the baud rate.

If you see framing errors or overruns try increasing the stop bits to 2 (on both sides). The stop bit is actually a delay inserted between the last data bit of the current frame and the start bit for the next frame. That gives the receiver an extra bit time to align to the next start bit. Worst case you will have to insert delays between characters, in which case you might as well lower the baud rate since your thruput is going to be lower anyway.

Jack Peacock

[Tesla DeLorean]

The internal HSI/MSI clocks would work fine. USART serial data can tolerate quite significant amounts of clock deviation. Requirements for USB and CAN are significantly tighter.