While USART (receive from PC and transfer of gained information back, pic. 1) perfectly works on low baud rates like 9600, use of high baud rates leads to obscure results (bad receive and OK transmit, pic. 2)
Higher rates are less tolerant to jitter or clock mismatch. Although 14400 shouldn't be a problem. Check to make sure the clock is accurate, pipe MCO out and measure frequency. If you're using HSI, ensure HSITRIM is set properly per the datasheet/reference manual.
"If you feel a post has answered your question, please click ""Accept as Solution""."
This is exactly how a mismatch in clock rates would manifest. A logic analyzer will be enough to show the signal rate on the line. Double check that the speed, parity, and stop bits settings are identical on both the STM32 and the receiving PC.
It can be frustrating, but there is an explanation and solution if you want to spend the time to find it.
"If you feel a post has answered your question, please click ""Accept as Solution""."
I wonder. If you have your clock frequencies high enough that you can divide good frequencies to the UART, then what else can go wrong. Is your ARM fast enough. Can your chip drive IO well. Can your system handle single bytes, but not several with zero delay between them.
I don't understand, 115200bps is typical baudrate for many applications, maybe because long ago the 2 wire I2C bus was 100kbps. I can make rs232 with HC05 module at 115200bps using HSI internal clock. No sweat bringup. It seems the issue is something like something obvious and overlooked.
