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.
