STM32F103C8 (Blue Pill) UART 300bps 7E1 Data Corruption Issue - Loopback Test Failed

[tqhuy]

Hi everyone,

I'm experiencing a persistent and perplexing issue with UART communication on my STM32F103C8T6 (Blue Pill) board. I'm trying to communicate with an energy meter using the IEC 61107 standard, which requires 300 bps with 7 data bits, Even parity, and 1 stop bit (7E1) during the initial handshake.

While my setup works flawlessly at higher baud rates (e.g., 600 bps, 9600 bps) with other configurations, I consistently encounter data corruption (receiving garbage characters or no response) specifically at 300 bps, 7E1.

Here's a detailed breakdown of my setup, troubleshooting steps, and observations:

1. Hardware Setup
MCU: STM32F103C8T6 (Blue Pill board)
Development Environment: Arduino IDE (with STM32Duino core, latest version)
UART Peripheral Used: USART2 (PA2/PA3) for communication with the energy meter.
External Interface: MAX485 module (for RS485 conversion) connected to an optical probe for the energy meter. (Note: The problem persists even when bypassing the MAX485 and connecting directly to a USB-to-TTL converter for loopback/testing).
2. Clock Configuration & Baudrate Accuracy
I've meticulously configured the clock and checked the baud rate error using STM32CubeIDE to ensure maximum accuracy:

System Clock: Configured to use HSE 8MHz (external crystal on Blue Pill) with PLL to achieve a 72MHz System Clock (HCLK).
3. UART Configuration (STM32CubeIDE confirmed)
The UART (USART2) is configured as follows in STM32CubeIDE:

Baud Rate: 300 bps
Word Length: 7 Bits
Parity: Even
Stop Bits: 1 Stop Bit
Hardware Flow Control: Disabled (asynchronous mode)
4. Conclusion & Question

Based on the repeated failure of the internal Loopback Test at 300 bps 7E1, it strongly suggests that the hardware UART on this STM32F103C8T6 chip is struggling with this specific low baud rate and frame format.

Has anyone else encountered similar issues with STM32F103C8 (Blue Pill) UARTs at very low baud rates like 300 bps, especially with 7E1 configuration?
Are there any known silicon errata or specific workarounds (beyond standard clock optimization) for the STM32F1 series UARTs at these extreme low speeds?
Could there be a subtle configuration setting I'm missing that disproportionately affects 300 bps communication, even if the error percentage looks fine?
Any insights or recommendations would be greatly appreciated!

Thank you.

[AScha.3]

Hi,

the uart2 is on APB1 clock, so to get to super slow baud rate, need lower the clock:

Then can have low baud...

btw

How you set 7N1 ?   My F103 uart can only : Programmable data word length (8 or 9 bits)

So set to 8 bit , 8N1 , and handle the parity in software ?

from rm ->

[Ozone]

> While my setup works flawlessly at higher baud rates (e.g., 600 bps, 9600 bps) with other configurations, I consistently encounter data corruption (receiving garbage characters or no response) specifically at 300 bps, 7E1.

Have you tried to review this signal on a scope, IMHO most importantly directly at the MCU UART pins ?
Did you check if any of the error flags in the UART peripheral status register gets set ?

[Andrew Neil]

---

@tqhuy wrote:

STM32F103C8T6 (Blue Pill) board. .

---

So that will not be a genuine ST part.

Have you tried with a genuine ST part?

---

@tqhuy wrote:

Development Environment: Arduino IDE (with STM32Duino core, latest version).

---

For STM32Duino support, see: https://www.stm32duino.com/

Maybe also ask on the Arduino forums.

Have you tried with just plain C code?

---

@tqhuy wrote:

I've meticulously configured the clock and checked the baud rate error using STM32CubeIDE to ensure maximum accuracy:.

---

But have you measured the actual rate at the pins?

---

@tqhuy wrote:

Are there any known silicon errata or specific workarounds (beyond standard clock optimization) for the STM32F1 series UARTs at these extreme low speeds?

---

Again, it's not a genuine ST chip - so it may have its own errata or performance issues ...

[Ozone]

> Again, it's not a genuine ST chip -  ...

I don't know if "blue pill" automatically equals a faked STM32 MCU.
But if it so in your case, you are more or less on your own - because the faked MCU does not adhere to the behavior described in the datasheet and reference manual.

[mƎALLEm · Accepted solution]

Hello @tqhuy and welcome to the community

ST resources are only dedicated to supporting genuine ST products. We are not committed to ensuring that clones/fakes products work properly with the firmware we provide.

This thread will now be locked. However, if you face difficulties while using genuine ST products, we’re here to assist you. Please feel free to start a new thread, and our team, along with community members, will be ready to help you with any issues/questions you encounter.

Thank you for your understanding.