UART/Timing and trouble/What the line can tell you
Lesson 9 of 12 · in 3D and VR

What the line can tell you

A UART receiver can notice four things about what it was given, a framing error, a parity error, an overrun and a break. Three say a frame was bad and one says bytes were lost. None of them says why.

Lonely BinaryUpdated 2026-10-014 min readNo board required

View it in VR

Lesson 9 of the UART course opens in a VR headset, on a table in front of you, and a voice starts three seconds after you arrive. Type this short address into the browser on a headset such as Meta Quest or Apple Vision Pro, and press Enter VR. No headset? Press Start the lesson: the same lesson, full screen.

learn.lonelybinary.com/vr/uart/9

The receiver has no idea what a message is. It checks each frame against the settings it was given, and it keeps a few flags about what it found. A program that reads those flags learns that something went wrong, and nothing more.

A bad frame

Framing error. A frame ends with a high stop bit. When the receiver takes its reading where the stop bit should be and finds the line low, it flags a framing error. The ESP32's UART raises an interrupt for it, and by default the bad byte is still stored in the receive FIFO, with the flag beside it. A wrong baud, a wrong frame setting, a break, a floating line or noise can each produce one. The flag does not say which.

Parity error. If parity is on, the receiver counts the ones in the data and the parity bit, and flags a frame whose count is wrong. Lesson 4 showed what that catches and what it misses. On the ESP32 the byte is still delivered, with the flag, and nothing says which bit was wrong.

Break. A break is the line held low for longer than one whole frame: the start bit, the data bits, any parity bit and the stop bit, all low. A receiver sees it as a zero byte with a framing error. It is not a byte. It is a long low, which a sender can produce on purpose. The ESP32's UART has a break interrupt, and its transmitter can send one by sending zero characters in a row.

Lost bytes

Overrun. The receive buffer was full when the next byte arrived, and bytes were lost. Every frame on the line was good. The fault is in the receiver, which fell behind, and so the wire is the wrong place to look. The ESP32's UART has an interrupt for it, and the ESP-IDF driver passes it on as an event. In Arduino code you rarely see any of these flags, so you see their effects instead: wrong characters, a message with a piece missing.

None of them says why

The flags describe an event at the receiver. A framing error from a wrong baud and one from a wrong frame setting look the same. The way to find a cause is to change one thing at a time: match the settings, shorten or re-seat the wire, lower the baud, make the program read sooner.

The 16550 family put these four flags in one line status register, and the ESP32 reports them as separate interrupts. The idea is the same.

Common mistakes

  • Reading a framing error as a bad cable. It means the stop bit was low. Wrong settings, a break and noise all do that.
  • Treating a parity error as a fixable byte. The byte is stored as received, flagged. Parity gives you no way to repair it.
  • Searching the wire for an overrun. The frames that arrived were good. The receiver was too slow or its buffer too small.

Edit this page — content/fundamentals/uart/what-the-line-tells-you.mdx

Discuss this article

Ask about this page. The answer stays here, on the page it belongs to, for whoever hits the same wall next.

Browse Fundamentals on the forum →