UART Overrun Error (ORE) on STM32H563 Without Hardware Flow Control

[NavaneethanN]

I am working on UART communication between an STM32H563 and a Raspberry Pi CM4.

Currently, I am using UART without hardware flow control (RTS/CTS disabled). During continuous communication, I am frequently getting ORE (Overrun Error) on the STM32 side.

Configuration details:

• MCU: STM32H563
• Communication: UART
• Flow control: Disabled
• UART mode: Interrupt
• Peer device: Raspberry Pi

I would like to know:

1. What is the best workaround to avoid ORE errors without enabling hardware flow control?
2. Is it reliable to use UART communication continuously without RTS/CTS?
3. What are the recommended UART settings or software handling methods for STM32H5 series?
4. How should ORE recovery be handled properly in STM32H563?

Currently, once ORE occurs, The data became lost.

[Andrew Neil]

You still haven't said what baud rate you are using

[NavaneethanN]

oops sorry, the baud rate is 115200

[Andrew Neil]

That is not a "very high" baud rate!

As already noted, you really shouldn't need to go to DMA for that.

Anyhow, if your question is now answered, please mark the solution on whichever post you feel resolved the issue (not this one!)

[NavaneethanN]

Yes, you are correct. Currently, we are using the ISC module, which introduces some delay, and we are not able to remove it. That’s why, in our existing setup, we moved to using UART with flow control for communication. We have also decided to move the display section from the controller to the processor side.

We are already using UART communication between the RPi CM4 and the H563ZIT6, but we are encountering an ORE (overrun error). That’s why we are asked for suggestions and possible solutions.

[Andrew Neil]

---

@Andrew Neil wrote:

---

@NavaneethanN wrote:

3. What are the recommended ... methods for STM32H5 series?

---

The above is entirely general - Not specific to any particular microcontroller.

---

One thing the STM32H563 has - which not all other microcontrollers have - is an 8-byte FIFO:

So be sure to make full use of that !

[Pavel A.]

>  What is the best workaround to avoid ORE errors without enabling hardware flow control

As Andrew noted, 115200 is not a high baudrate, if your program cannot reliably handle it with interrupts - then, of course use DMA. With DMA the UART FIFO is not required.

Without DMA, the FIFO alone won't prevent overrun. So:

 - Be always prepared to handle ORE and dismiss it. It can occur even while initializing the UART when you are not ready to handle it yet.

- Use protocols with error detection and retries (Ymodem, etc) to correct any kind of transient errors. Sending raw text is not reliable.

- If you have to receive a lot of raw text, use DMA (correctly! look for examples)  or reduce the baudrate.

[Andrew Neil]

---

@Pavel A. wrote:

the FIFO alone won't prevent overrun.

---

Indeed.

But, if used correctly, it should help avoid it happening...