2026-02-10 8:43 PM - edited 2026-02-10 8:46 PM
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,
Solved! Go to Solution.
2026-02-15 10:42 PM
> 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.
2026-02-12 6:11 AM - edited 2026-02-12 6:12 AM
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.
2026-02-14 2:02 AM
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.
2026-02-15 10:31 PM
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.
2026-02-15 10:42 PM
> 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.