stm32wle5 - internal clock derivation for LPUART

[Piotr Romaniuk]

Hi,

I work with stm32wle5 where AT commands are received from LPUART. This interface is setup for 9600 bps / 8N1 and its baudrate clock is derived from LSE (32768Hz) clock. The chip is wake up by incoming characters.

I observe that transmitted bits have some jitter. Also I have problems on received characters - single bit errors, blocking HAL.

I saw that LPUART baudrate is determined by equation:

         fbaud=256 * fclk / lpuartdiv

I would like to understand how x256 is performed. Is there DLL loop inside? What bit jitter can I expect for 9600?

Regards,
Piotr Romaniuk

[Danish1]

Have you looked at the Reference Manual for your stm32? That has a section on the LPUART including a subsection on the baud rate generator.

Do come back to us if there are bits in there that you are struggling to understand. There is a lot of complexity and it is hard to take in on first reading.

[Piotr Romaniuk]

Hi,

yes I read it.

Everything is set properly, but errors appears. More serious is that the chip stops receiving data.

Transmitted characters comes from another stm32 that uses LPUART (clocked from LSE).

There is jitter in bits as well.

Regards,

Piotr Romaniuk

[Danish1]

My reading is that it is all done digitally.

I can imagine a "phase-accumulator", to which 256 is added every flck tick. (Or perhaps better, 128 every rising and 128 every falling fclk edge; I don't know which).

When the value in this phase-accumulator is greater-than or equal-to LPUARTDIV (minimum value 768), then LPUARTDIV is subtracted and a baudrate-clock-tick happens.

A consequence of this is that every baudrate-clock-tick is quantised to the nearest fclk tick (or half-tick). Hence lots of jitter (as a fraction of bit time) if you're using a high baud rate. And as your transmit and receive stm32s are not synchronised, you suffer from the total of transmission jitter and reception jitter.

What might be done to improve things?

• Prejudice: I don't like HAL. It is "quick and dirty" to get a demonstration working, but probably doesn't handle error conditions sufficiently well. You might get framing errors where the stop-bit is not found when expected. Writing your own code with proper error-recovery can help here.
• Changing baud rate. You could go slower. Or where you only go between stm32 LPUARTs, choose a baud rate that has no fraction in the LPUARTDIV e.g. 8192 baud

[Piotr Romaniuk]

Hi,

"I can imagine a "phase-accumulator", to which 256 is added every flck tick. (Or perhaps better, 128 every rising and 128 every falling fclk edge; I don't know which)."

Thank you, it may be done this way. I need a confirmation from ST.

"Changing baud rate. You could go slower. Or where you only go between stm32 LPUARTs, choose a baud rate that has no fraction in the LPUARTDIV e.g. 8192 baud" - I had the same idea. Jitter vanished, but problem is still present.
Further tests showed that it is related to very slow ISR-handler in HAL (your first suggestion). I agree with you that HAL is very poor code.

Regards,

Piotr Romaniuk