USART1 receives garbage data at 1.5 Mbits/second or Higher (STM32C542RC)

[vatsal]

Hi Team,

I am using the STM32C542RC on the STM32C5 Nucleo-64 board (MB2213),What is the max. supported baud rate for the USART baud rate?

We have checked that, with STM32CubeMX, the DIV1 prescaler, and oversampling by 16, the maximum supported USART baud rate is 9 Mbit/s, assuming the peripheral clock is configured appropriately.

However, in our setup, we are receiving garbage/corrupted data at 1.5 Mbit/s. Communication works correctly at 1 Mbit/s (TX and RX both working at this baud rate), but increasing the baud rate to 1.5 Mbit/s or higher in that case results in receiving garbage/invalid data.

 

The STM32 receiver and the sender are configured with the same UART settings:
Baud rate: 1.5 Mbit/s
Stop bits: 1 (also tested with 2)
Parity: None
Word length: 8 bits
Hardware flow control: None

 

Please check the above configuration and let us know how to achieve reliable data on the receiving end at a 1.5 Mbps or higher baud rate. If any additional configuration is required, then please let us know.

 

We need to support a higher baud rate with Tx and Rx both working, BUT due to this issue, we are not able to achieve that.

References

• STM32C542RC Datasheet:
  https://www.st.com/resource/en/datasheet/stm32c542rc.pdf
• STM32C5 Reference Manual (RM0522):
  https://www.st.com/resource/en/reference_manual/rm0522-stm32c5-series-advanced-armbased-32bit-mcus-stmicroelectronics.pdf
• STM32C5 Nucleo-64 board (MB2213):
  https://www.st.com/resource/en/user_manual/um3615-stm32c5-nucleo64-board-mb2213-stmicroelectronics.pdf

[Andrew Neil]

What is the max. supported baud rate for the USART

The datasheet should tell you that?

 

Garbage data on async links is usually due to wrong baud rate - see here.

So the first thing to check is that the baud rate is really what you think it is.

Also use an oscilloscope to check that the signals are still valid at 1.5Mbps.

 

Please give some more details of your setup:

• What is at the other end of the link ?
• How are they connected ?

Some good, clear photos of your setup could help.

 

 

[vatsal]

At the other end, Jetson Orin Nano Developer Kit Carrier Board is connected:
PIN 8: UART1_TXD     ↔     PB15: USART1_RX
PIN 10: UART1_RXD    ↔    PB14: USART1_TX
GND    ↔    GND

Jetson Orin Nano (Expansion Header Connections)

Commands:

1. Configure the UART:

stty -F /dev/ttyTHS1 1500000 cs8 -parenb -cstopb -crtscts -ixon -ixoff -ixany raw -echo

2. Send a message:

printf "hello world\n" > /dev/ttyTHS1

​​​Reference:

https://developer.nvidia.com/downloads/assets/embedded/secure/jetson/orin_nano/docs/jetson_orin_nano_devkit_carrier_board_specification_sp.pdf

 

 

 

[MM..1]

And ofcourse check if your clock tree is based on HSE and PLL is set right for 1,5Mb divider without error.

[Andrew Neil]

And ofcourse check if your clock tree is based on HSE 

Indeed.

 

​@vatsal using an internal RC oscillator is unlikely to give good baud rate accuracy - especially at such high speeds.

[Gyessine]

Hello ​@vatsal 

I’m quite confident that your issue is related to clock accuracy.

The USART has a maximum tolerance for clock frequency deviation. If this tolerance is exceeded, it can result in framing errors or garbled characters on the received data.

Could you please confirm which clock source you are using: HSI or HSE?

For high baud rates such as 1.5 Mbit/s, we strongly recommend using HSE, as it is typically much more accurate and stable than HSI.
Since HSI is less precise, it may cause the system clock to exceed the USART’s allowable tolerance.

You can also verify the clock accuracy using MCO, and calculate the allowed deviation based on the following section of the reference manual:

43.5.9 Tolerance of the USART receiver to clock deviation
BR
Gyessine

[unsigned_char_array]

For high baudrates I recommend using DMA for reception instead of interrupts.