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

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

I suppose you talk about Cube/HAL generated code here.
Go through your source code, and check what you do in interrupt context.
Mind you, all callback functions run in interrupt context, and block further Rx interrupts until they finish.

The best option is to reorganize the code, only copy received data to another buffer in the Rx interrupt, and process them in the main application / loop.

Second, there are "semantic" start/stop mechanisms for serial communication. Look up "Xon / Xoff".

And third, you can change the Raspberry code to go slower.

I've been using UARTs for about a quarter of a century, much of the time using small 8-bit microcontrollers, running with a very moderate clock frequency. Mostly, I've used RS485, where hardware flow contrrol isn't an option. Even with relatively small 8-bit microcontrollers, a bit rate of 115200 hasn't been an issue. Your microcontroller is hellishly fast, compared to most of what I've used.

To answer your four questions:

1. Use either interrups (my primary choice) or DMA to receive data.

2. Absolutely, if you do it right. If you want to communicate over long distances, I'll recommend using RS422 or RS485, rather than RS232.

3. I haven't exactly used an ST32H5. But on the H7 I've used ordinary receive interrupts.

4. That I cannot answer. But in general, if you get an ORE flag, data will be lost.

Unless you run the serial interface at a ludicrous speed, the microcontroller should easily be done handling one byte, long before the next byte has been received. A few advices for you:

As @Ozone mentions, keep the receive interrupt code as short as possible. I general, I do only a few things in the interrupt:

A. Check if the incoming byte is a "start of transmission" byte (only if relevant in the protocol you are using)

B. Copy the received byte to a buffer. I typically use a global array for this.

C. If the received byte is an "end of transmission" byte (such as <CR> or <LF>), set a flag (boolean variable) to indicate to the main code that a full transmission is waiting in the buffer.

I always handle what has been received in the main code, so I don't spend loads of time in an interrupt. In case of duplex communication (i.e. not RS485), I may copy the receive buffer to a work buffer, so a new transmission can tick in while I handle the present one. Or I may use a ring buffer.

You also need to make sure that other code doesn't block your receive interrupt for a long time. ("A long time" here is the time it takes to fill the microcontroller's receive buffer / FIFO.)

Yes XON / XOFF flow control may be an option, if your connection permits it. But in my opinion, it is better to figure out why you are getting overrun errors in the first place. Suggestion: if you have an available output pin and an oscilloscope, connect the scope to that output pin and the UART receive pin. Then, in the receive interrupt, set the output pin high in the beginning of the interrupt, and low in the end. Using the oscilloscope, this can tell you how quickly the microcontroller responds to the received data, and how much time it spends in the interrupt. This may, in turn, help you figure out where your problem is.

In general, with a fast microcontroller, you shouldn't get overrun errors at all.

---

@NavaneethanN wrote:

1. What is the best workaround to avoid ORE errors without enabling hardware flow control?

---

Overrun means that more data arrives before you've cleared existing data from the UART's hardware receive buffer.

So, if you're getting Overrun errors, it means your code is taking too long to handle received bytes.

This suggests that you are doing too much in your interrupt handler.

The solution is to ensure that your Rx byte handling takes less that 1 byte period.

Note that HAL can add some significant overheads ...

---

@NavaneethanN wrote:

2. Is it reliable to use UART communication continuously without RTS/CTS?

---

Sure it is!

The general approach is to have the ISR just read the received byte from the UART and put it into a software buffer (eg, a ring buffer) - further message handling occurs elsewhere.

You haven't said what baud rate you're using, but this should certainly be fine for 115200.

For very high baud rates, you might change to DMA ...

---

@NavaneethanN wrote:

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

---

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

---

@NavaneethanN wrote:

Currently, once ORE occurs, The data became lost.

---

Yes, once the error occurs, that data has been lost - it cannot be recovered.

This is why we have error detecting & correcting protocols ...

> You haven't said what baud rate you're using, but this should certainly be fine for 115200.

Yup, absolutely. I have routinely used 230400 on much slower microcontrollers. And with RS485, where hardware flow control isn't possible.

The trick with (all) interrupts is to do only what is strictly necessary, and then get out. Don't sit around calling functions or formulate a reply.

Sorry for the late reply, and thank you for your responses.

For very high baud rates, switching to DMA seems like a good approach.
My team has recently started working on the DMA concept, so we are currently exploring it. If I face any issues, I will reach out here.

Thanks

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.

>  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.