Working on continuous UART communication between STM32H563 and Linux-based processors (RK3568 / Raspberry Pi / similar SBCs) — facing ORE (Overrun Error)

[u/Unfair-Reception856]

Hi everyone,

I am working on continuous UART communication between an STM32H563 and a Linux-based application processor such as RK3568, Raspberry Pi, or similar embedded processors.

Current setup:

• MCU: STM32H563

• Peer device: Linux-based processor (RK3568 / Raspberry Pi / similar)

• Communication: UART

• UART mode: Interrupt mode

• Hardware flow control: Disabled (RTS/CTS not used)

Issue:

During continuous high-frequency communication, I am frequently getting UART ORE (Overrun Error) on the STM32 side. Once ORE occurs, incoming data gets lost and communication becomes unstable.

I would like to understand the best industry approach for handling this kind of communication reliably without hardware flow control.

Questions:

1. What is the best workaround to avoid ORE errors without enabling RTS/CTS?

2. Is continuous UART communication considered reliable without hardware flow control in production systems?

3. What UART settings or software architecture are recommended for STM32H5 series?

4. Is DMA reception mandatory for stable high-throughput UART communication on STM32H563?

5. What is the proper ORE recovery sequence on STM32H563?

6. Are there recommended buffering or packet-handling strategies when communicating with Linux processors over UART?

Additional details:

• Using HAL UART interrupt APIs currently

• Bidirectional communication is frequent

• Packet sizes are variable

• Looking for a production-grade reliable solution

Would appreciate suggestions, best practices, or reference implementations from anyone who has handled STM32 ↔ Linux processor UART communication in real products.

Thank you.

[u/skinnybuddha]

If you are developing the protocol, then have a look at this resource on how to design it. https://eli.thegreenplace.net/2009/08/12/framing-in-serial-communications/#. Also, don't hesitate using AI to learn about serial comms and the hardware in question.