What error conditions can UART hardware detect, and how should firmware handle them?

UART peripherals detect four error conditions, each flagged in the status register:

• Framing error — the expected stop bit is not high. This usually means baud rate mismatch, noise corruption, or a break condition. It is the most common symptom of a misconfigured baud rate.
• Parity error — the number of 1-bits in the data plus the parity bit does not match the configured parity (even or odd). This indicates at least one bit was corrupted, but parity can only detect an odd number of bit errors — two flipped bits cancel out and go undetected.
• Overrun error — a new byte arrived before firmware read the previous byte from the receive data register. The hardware has no room to store it, and data is lost. This is the most dangerous error in production because it happens silently under load.
• Noise error (on some MCUs like STM32) — the three internal samples taken per bit did not all agree. The majority value is used, but the hardware flags that the bit was noisy.

Firmware should check error flags after every received byte (or in the receive ISR). For framing and parity errors, discard the byte and optionally request retransmission at the application layer. For overrun errors, the root cause is that the firmware is not draining the receive register fast enough — the fix is to use DMA or interrupt-driven reception with a ring buffer rather than polling. Simply clearing the error flag without addressing the throughput problem guarantees it will recur.