cancel
Showing results for 
Search instead for 
Did you mean: 

LPUART missing first bit when using LSE, Works fine with HSI

JWieb
Associate III

We am using the Murata 1SJ which has a STM32L072CZ MCU and internal LSE, We trying to decode a UART stream from a Ublox GPS device using the LPUART in STOP mode. BAUD 9600 8 bits, 1 stop, no parity, all standard stuff.

When i clock the LPUART with HSI16, everything works...

When i clock the LPUART with LSE, on occasion the first bit is missing. Without it the whole packet is lost. Maybe 1 in 10 packets this happens. I'm getting 0x94 instead of 0xB5. The LSE is giving us a rock solid 32,768Hz.

Anyone have any tips or next steps to try here?

1 ACCEPTED SOLUTION

Accepted Solutions
JWieb
Associate III

This comment was the winner. You need to set UCESM bit so the LPUART ALWAYS receives the LSE clock in stop mode. Otherwise the LPUART doesnt always start fast enough. Seems like its just on the edge.

With this bit set it seems rock solid. so far a few thousand packets with no error.

https://community.st.com/s/question/0D53W00001QgmDOSAZ/lpuart-acts-strange-with-stopmode-stm32l081kzt6

ST should add this line to thier low level examples.

LL_LPUART_EnableClockInStopMode(LPUART1);

View solution in original post

4 REPLIES 4

This may be a disappointment, but 9600 baud is a tad bit beyond the capabilities of LPUART, regardless of what the RM boasts about. In particular, if zeros and ones on the Rx pin are not 1:1 of width, or, more precisely, if the startbit is a bit shorter than it ought to be, together with the usually non-negligible cycle-to-cycle jitter of LSE (which in long term still may be rock solid 32.768kHz) may result in sampling the "middle" of startbit to fall just at the beginning of subsequent 0th bit. You can confirm if this theory is correct - if it's so, the "lost" bytes are always those which have 1 as the 0th bit.

Probably the best solution would be to use a lower baudrate. You can also try some hardware solution to stretch the zeros and shorten the ones.

JW

JWieb
Associate III

This comment was the winner. You need to set UCESM bit so the LPUART ALWAYS receives the LSE clock in stop mode. Otherwise the LPUART doesnt always start fast enough. Seems like its just on the edge.

With this bit set it seems rock solid. so far a few thousand packets with no error.

https://community.st.com/s/question/0D53W00001QgmDOSAZ/lpuart-acts-strange-with-stopmode-stm32l081kzt6

ST should add this line to thier low level examples.

LL_LPUART_EnableClockInStopMode(LPUART1);

Hi @JWieb​ ,

Thanks for sharing your finding, very interesting.

> ST should add this line to their low level examples.

==> to which example exactly are you pointing? I checked some examples from STM32CubeL0 package and found that HSI is used there.

-Amel

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Sorry i should have elaborated more. If STM wants to demonstrate the full ability of the LPUART those examples should use the LSE clock instead of the HSI. Thus showcasing how a user can run the LPUART in its lowest state while running.

Since the the most common application of the LPUART is for receiving GPS packets while the MCU is in stop mode.

Thank you,