Showing results for 
Search instead for 
Did you mean: 

Uneven bit timing on STM32L4R5/U575 LPUART when using LSE 32.768kHz source clock

Associate II

On the L4R5 and on the U575 when the LPUART uses the LSE clock source (32768Hz) and is configured for 9600 baud the byte timing is very precise, exactly as predicted by the reference manual as (RM0432, 51.4.7). However the timing of individual bits within the byte deviates very significantly from the ideal (+/- 10uS error!)

We’re troubled by our inability to offer an explanation to our customers.

Through a series of experiments we determined that the uneven bit timing is a function of using the LSE as the clock source, and is independent of the PCLK/APB (the PCLK is 80MHz in the image below). If we change the LPUART clock source to use the default MSI (4MHz on the L4R5) the bit and byte timing is precise, but since we rely on the LPUART in STOP2 mode this isn't an option for the production firmware.

I’ve attached a capture from a logic analyzer. For a 9600 baud 8N1 UART one would expect a byte time (8 data, 1 stop, 1 start) to have a duration of 1.04ms – which I what I measured (the 1.07ms likely includes a small delay for the UART transmit data register to be refreshed.

Likewise the bit times are expected to be around 104us – a tenth of the byte time. However you can see that the duration of the high voltage is highly variable, and as low as 92us – a big timing error for a UART.

We double checked that this is not a function of the sampling rate of the logic analyzer.

According to the reference manual the LPUART baud rate is calculated as (RM0432, 51.4.7)

baud = (256 × lpuartckpres)/LPUARTDIV

If lpuartckpres is 32768Hz the 256 multiplier might be expected to give a time granularity of 0.1us – but the logic analyzer is showing bit timing deviations of > 10us, and since the pclk is 80MHz we’re at a loss to explain such large bit timing deviations.

Perhaps we are doing something wrong, or perhaps it’s a limitation of the STM32 LPUART hardware architecture ? Would appreciate if anyone has insight. Thanks.

Lead III

This is how LPUART works. Still, I cannot see anything wrong with it as long as there is no danger of having 3 middle-bit samples inconsistent.



We also see this behaviour on the STM32L496, with bit timings varying from 92us to 120us

When using LPUART to drive an RS485 bus via an LTC2862HDD, CH340 based USB adapters produce a significant number of corrupted bytes (~1-3%). FTDI based adapters seem resilient to the varying bit times. 

We found that slowing the LPUART clock to 5575 baud removed Tx corruptions but introduced Rx corruptions.

Unless we think of something more elegant we're going to resort to using LPUART for Rx and Wake, and another UART for Tx. Not ideal.




This post looks relevant..