STM32H7 UART BAUD RATE ISSUE

[Iivan.1]

Hello! I'm developing application using STM32H745 with uart interface. The problem is the behaviour of uart baudrate. I configure with hal driver uart on baudrate 115200 and try echo with terminal. The problem is that sometimes i recieve wrong data in some bits. The is always the same error for the same bit. For example, I send 85 (1010101) but around 2 times of 10 i recieve 170(10101010) and it seems, like uart take stop bit also as LSB bit. Than i watched with scope and measure frequence, that sends terminal and MCU uart and it's clear, baud rate is 115200 as it expected(BRR prescaller seems to be OK). Than I substract 5-10 from BRR prescaller (baudrate becomes to 115700-116000 on MCU, terminal still sends 115200, on scope frequence changes, and MCU start recieving correctly). There no such issue on baudrate like 512000, 900000 or smaller like 2400, 4800.

It seems, like there is different baudrate on recieving and transmiting (but i understant, that there is no way for this). When i configure MCU on 115200 and send 114000, all is clear. Or MCU 116400, terminal 115200.

I dont understand what is going wrong. I would be grateful for any ideas!

[Andrew Neil]

What clock source are you using?

For accurate baud rates, you should use a crystal ...

[Iivan.1]

there is no problem with clock source of MCU. As a mentioned, i measure baudrate on MCU, when it transmits, its ok. Also on this board already working sdram, spi fram, and lan.

[Andrew Neil]

So what source are you using?

"It seems, like there is different baudrate on recieving and transmiting  (but i understant, that there is no way for this)"

Actually, there is:

When the MCU is transmitting, the baud rate is set by the MCU;

When the MCU is receiving, the baud rate is set by the PC.

It's quite possible that the PC is more tolerant of baud rate errors than the MCU - so it receives fine, but the MCU doesn't.

"it seems, like uart take stop bit also as LSB bit"

If you think about the way errors occur, then they will accumulate over the frame - so it's naturally going to be the final bit(s) where errors are observed...

[waclawek.jan]

What's your hardware? Try different bytes than the alternating 0/1. Try a longer sequence of bytes.

JW

[Johi]

Uart's receive abilities relate to the clock deviation: see RM0399 reference manual.

https://www.st.com/resource/en/reference_manual/rm0399-stm32h745755-and-stm32h747757-advanced-armbased-32bit-mcus-stmicroelectronics.pdf

Your uart clock is generated throug a PLL, is your PLL operating within its frequency spec (see my post of yesterday). If not it can be unstable. (If are you using MX configurator, then illegal configurations turn red).

Have you tried to connect TX and RX on your board so the board receives and sends using the same clock. This should work flawlessly for a long time (just to make sure that part works properly in all cases)?

I had a similar problem with the RS232C port on my dell workstation: after 10 bytes, from time to time wrong byte always on the same byte. The culprit seemed to be the port itself, with a new PCI RS232C serial card, all problems were gone. The origin I still do not understand.

[Andrew Neil]

@Johi​  makes excellent points:

"Uart's receive abilities relate to the clock deviation"

Indeed; and that may be different on each side - the MCU's receiver is not the same as the PC's receiver.

"is your PLL operating within its frequency spec ... If not it can be unstable"

+1

Also, are you sure that the oscillator is actually at the correct frequency?

Does the STM32H745  have a pin that can output the system clock?

"Have you tried to connect TX and RX on your board"

+1 - ie, a loop-back test.