RS422 Receiver Not Reporting Errors When Too Few Stop Bits

I am interfacing with a device (the transmitter) which configures its serial settings to 8 data bits, no parity, 1 stop bit at a baud rate of 115200. These are known values and fixed values I can't edit or change.

The transmitter is connected to a computer via an FTDI USB-COM422-PLUS4 which uses the FTDI FT4232H chip to decode serial into USB and present it as a virtual com or TTY device.

For fun and my own understanding of both serial communication and the Linux driver, I've been experimenting with connecting to the transmitter at incorrect serial settings and looking at what errors are reported (framing, parity).

When I connect to the transmitter with 8 data bits, no parity and 2 stop bits, I would expect to see some sort of error, likely framing, since the transmitter only sending 1 stop bit. But there are no errors of any time I can find reported. Data is received normally. I can confirm the transmitter is 1 stop bit via a logic analyzer.

Are most receivers going to ignore a missing stop bit like this? Any reasons this wouldn't be presented as an frame error? Or could it be a quirk in the FTDI chip that it ignores this kind of error?

2 Answers

Most modern UARTs will receive with one stop bit no matter how they're set up.

The two stop bit thing is an instruction to the transmitter, to send data that a picky receiver can deal with.

Two stop bits is really a remnant of an older, bygone age.

• Well two stop bits make sure that even for drifting clocks sender and receiver are "on the same page" i.e. even if their clocks diverge the two clock cycles make sure that both have enough time to reach the "resting" state. Especially if one uses the far from perfect internal oscillators and high baud rates. So I would disagree with the claim that it is just a remnant. – Christian B. Aug 21 at 22:59

A framing error is a logic low in the STOP bit position, rather than the correct logic high. The STOP bit position is 'n' bits after the START bit (logic low). 'n' depends on if you're using 8-bit or 9-bit data and if you're using parity:

 9 for 8-bit data, no parity
10 for 8-bit data, parity
10 for 9-bit data, no parity
11 for 9-bit data, parity


Transmitters are usually configured to send multiple STOP bits because the receiver cannot deal with the incoming byte rate and may overrun. STOP bits after the first are pauses in transmission and not part of the byte framing.

Older systems generated an interrupt to a relatively slow CPU for every received byte. Some receivers didn't have input buffer registers, so the next incoming bit would corrupt the byte just received. Bytes took time to unload.

These days, CPUs are typically very fast compared to baud rates and buffering circuitry is cheap, so your average system can keep up with streams with 1 STOP bit between bytes.

EXAMPLE DATASHEET TEXT

NAT SEMI PC16550 (used in huge numbers in PCs in 1990s)

The Receiver checks the first Stop bit only, regardless of the number of Stop bits selected.

NXP SC2692

After the stop bit is detected, the receiver will immediately look for the next start bit. However, if a non-zero character was received without a stop bit (framing error) and RxD remains Low for one half of the bit period after the stop bit was sampled, then the receiver operates as if a new start bit transition had been detected at that point (one-half bit time after the stop bit was sampled).

Framing Error A framing error occurs when a...stop bit are zero. If RxD remains low for one half of the bit period after the stop bit was sampled, then the receiver operates as if the start bit of the next character had been detected.

• Interesting. So even if the transmitter then sends the start bit (logic low, I think?) into the 10th bit, instead of a second bit time of logic high, that doesn't get considered a problem? Maybe it doesn't even care/sample after the first bit time of logic high? – Trenton Holmes Aug 22 at 20:13