Skip to main content
Associate
February 11, 2026
Solved

UART Overrun (ORE) Error in STM32CubeMX-Generated Code for STM32H573RIT6.

  • February 11, 2026
  • 2 replies
  • 308 views

Hello STM Community,

I'm encountering persistent UART Overrun (ORE) errors on the STM32H573RIT6 when using code generated from a fresh STM32CubeMX project (.ioc file).

Setup and Reproduction:

  • Created new STM32CubeMX project for STM32H573RIT6

  • Generated code and tested UART reception with:

    • HAL_UART_Receive_IT()

    • HAL_UARTEx_ReceiveToIdle_IT()

  • Result: Continuous ORE errors in both interrupt and IDLE modes

Key Observations:

  • Issue persists even at:

    • Reduced system clock frequencies

    • Lower baud rates

    • With non-blocking ISR implementation

  • DMA Mode Works Perfectly:

    • HAL_UART_Receive_DMA()

    • HAL_UARTEx_ReceiveToIdle_DMA()

    • No ORE errors observed

Comparative Testing:

  • Regenerated multiple fresh CubeMX projects for STM32H573RIT6 → ORE persists

  • Used older .ioc file with UART configuration → No ORE

  • Created new CubeMX project for NUCLEO-G071RB → UART interrupt/IDLE works perfectly, no ORE

Question:
Could this indicate a CubeMX configuration issue specific to STM32H573RIT6 UART peripheral initialization?

Any insights from ST engineers or experienced developers would be greatly appreciated.

Thank you,

Best answer by Ozone

> This is a code issue. To debug, you'll need to show the code you're using.

And more often than not, the problem is within the user-written callback functions.

 

2 replies

Ghofrane GSOURI
Technical Moderator
February 12, 2026

Hello @MR8 

To investigate the UART ORE issue, a practical workaround is to compare the entire old working project with the new problematic project using WinMerge. open both project root folders in WinMerge and run folder comparison  to identify what changed between the working and non‑working setups.

THX

Ghofrane

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
MR8Author
Associate
February 14, 2026

Hello Ghofrane,

Thank you for the suggestion.

I have already compared the old working project and the newly generated project using WinMerge. The UART configuration parameters (baud rate, word length, stop bits, parity, FIFO configuration, NVIC settings, clock configuration, etc.) are identical between the two projects.

Additionally, I reproduced the issue using a minimal project generated from a fresh CubeMX .ioc file with only:

  • SystemClock configuration

  • Single UART initialization

  • HAL_UART_Receive_IT() / HAL_UARTEx_ReceiveToIdle_IT()

Even in this minimal setup, ORE occurs consistently on STM32H573RIT6.

The same test on STM32G071RB works correctly with interrupt/IDLE mode.

Thank you for your support.

TDK
Super User
February 16, 2026

ORE happens when characters are received without the previous ones being read out. This is a code issue. To debug, you'll need to show the code you're using.

The CubeMX-generated code doesn't call any HAL_UART_Receive* functions.

 

You can also go off of one of the working examples that use HAL_UART_Receive_IT.

STM32CubeH5/Projects/NUCLEO-H533RE/Examples/UART/UART_HyperTerminal_IT at 7c60a8388c4e91cfab12bc9f6c10b024c43b0722 · STMicroelectronics/STM32CubeH5

"If you feel a post has answered your question, please click ""Accept as Solution""."
Ozone
OzoneBest answer
Principal
February 16, 2026

> This is a code issue. To debug, you'll need to show the code you're using.

And more often than not, the problem is within the user-written callback functions.