cancel
Showing results for 
Search instead for 
Did you mean: 

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

MR8
Associate

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,

1 ACCEPTED SOLUTION

Accepted Solutions
Ozone
Principal III

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

 

View solution in original post

4 REPLIES 4
Ghofrane GSOURI
ST Employee

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.

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

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
Principal III

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