Serial Parity and Framing Errors in Gateways: Preserve UART Evidence Above the Byte Stream

A gateway that reports only “CRC failed” or “response timed out” may have discarded the evidence needed to explain the failure. The UART could have detected parity errors, invalid character framing or receive overrun before the protocol parser saw any bytes. Preserve those observations as a separate diagnostic channel instead of compressing every failure into a Modbus error.

This guide uses Linux 6.6 serial and TTY interfaces as a concrete implementation boundary, alongside Modbus Serial Line V1.02. USB adapters, vendor kernels and microcontrollers may expose different information. The procedure is a proposed diagnostic design, not a report of tested hardware.

Record the effective character format

Record baud rate, data bits, parity, stop bits, flow control, controller or adapter model, driver and kernel build. Read back the configured settings where possible. A UI label, saved configuration file and active UART programming can disagree after a failed setting change or another process opens the port.

The serial specification, section 2.5.1, describes RTU’s eight data bits, default even parity and an extra stop bit when parity is absent. Do not treat 8N1 as a universal standards default just because a particular product supports it. Match the actual documented device format before interpreting error counters.

Keep three receiver observations distinct

A parity indication reports a failed parity check under the receiver’s configured format. A character framing indication typically concerns an invalid stop-bit observation. An overrun indicates that a receiving stage could not preserve all arriving data. Consult the controller manual for exact flag semantics, FIFO behavior and whether reading status clears it.

These are not the same as a Modbus frame-length error or CRC mismatch. A wrong parity setting can produce UART errors while the visible eight data bits happen to look plausible. An overrun can remove a byte without leaving an obvious “bad byte” to annotate. Conversely, protocol failures can occur with no UART error indication, including when evidence was never exposed by the adapter.

Trace status through the actual driver path

Linux’s 6.6 Low Level Serial API describes read and ignore status masks configured by set_termios. INPCK enables frame/parity events to reach the TTY layer, while IGNPAR affects whether error characters are discarded. The same captured electrical input can therefore become different application-visible bytes under different input policies.

The 6.6 TTY buffer API supports character flags, but that does not promise every low-level driver supplies accurate per-byte status. Inspect the selected driver’s receive path, including DMA or USB status processing. Record unsupported evidence as “unavailable,” rather than treating a permanently zero counter as proof that the link is clean.

Do not feed diagnostic markers into a binary parser

Ordinary read calls return bytes, not a portable array of UART status objects. Linux TTY input processing can discard, replace or mark exceptional characters depending on termios settings. PARMRK can introduce marker sequences and escape a valid 0xFF byte. Its behavior belongs to the line-discipline boundary, visible in the Linux v6.6 N_TTY implementation.

Do not enable marking and pass the resulting stream unchanged to a Modbus parser. Either decode that representation correctly before framing, retaining associated error information, or use a driver-specific diagnostic channel that leaves payload handling explicit. Break handling, input stripping and software flow control also require deliberate settings. “Raw mode” alone does not document which evidence your application retains.

Correlate counters without inventing byte precision

Where supported, obtain serial error counters before and after a bounded capture window. Linux defines parity, frame, overrun and buffer-overrun fields in serial_icounter_struct in the v6.6 UAPI; whether an adapter and driver implement useful values must be checked. Preserve the distinction between receiver overrun and later software-buffer loss.

For each window, retain counter deltas, monotonic timestamps, bytes received, valid protocol frames, CRC failures, discarded partial frames and request timeouts. Document counter width, reset behavior and sampling boundaries. A driver may aggregate errors, and a status read may cover several frames, so label the relationship “observed during this interval” unless the implementation supports a stronger association.

Run controlled mismatch tests on an isolated fixture

Begin with matching settings and an approved data source. Then change only one parameter, such as receiver parity, while retaining the original configuration for restoration. Predict which layer should report evidence, capture it, restore the known configuration and repeat the baseline. Never inject malformed control traffic into a production actuator merely to raise a counter.

Test whether the error is visible at hardware or adapter status, driver accounting, TTY representation and the application report. A pseudo-terminal can test your marker decoder and reporting logic, but cannot prove a real UART detects parity or overrun. Similarly, deliberate application slowdown does not guarantee hardware overrun because intermediate buffers may absorb the traffic.

Deliver a layered failure report

Report the serial configuration and evidence availability first. Then list observed receiver errors, byte transformations, protocol failures and transaction outcomes separately. If CRC failures rise without exposed UART evidence, leave both parser and transport causes open. If parity errors track a deliberate mismatch and disappear after restoration, describe that scoped observation without claiming every field failure has the same cause.

• Character format is verified against both endpoints.
• Driver and TTY error policies are documented for the deployed version.
• Diagnostic markers cannot become application payload accidentally.
• Unsupported counters are distinguished from valid zero counts.
• Fault injection and restoration produce a reproducible layered record.

This evidence directs the next investigation without replacing electrical measurements, RTU timing analysis or device-specific driver validation.