123 Main Street, New York, NY 10001

UART Frame Format: Start, Data, Parity & Stop Bits

← Back to: I²C / SPI / UART — Serial Peripheral Buses

Definition & scope: what “frame format” really means

UART frame format defines how one character is encoded on the wire: idle level, a start bit, N data bits (LSB first), an optional parity bit, and M stop bits. It is the structural contract that must match end-to-end.

Frame vs packet (avoid scope confusion)

  • Frame (this page): the per-character bit structure (start/data/parity/stop/idle/break). If frame format mismatches, decoding fails even if the waveform looks “alive.”
  • Packet (not this page): multi-byte protocol fields (header/length/CRC, application semantics). Keep packet design and parsing logic out of this subpage to prevent sibling-page overlap.

MUST-match checklist (end-to-end contract)

The following settings must be consistent across both endpoints (and across any bridge/adapter in between), otherwise bytes may look shifted, mirrored, or randomly wrong.

  • Data bits (N): 7/8/9 (or 5/6 in legacy cases). A wrong N causes “bit slip” at every byte boundary.
  • Parity mode: none / even / odd / mark / space. Any parity mismatch inserts or removes a bit position.
  • Stop bits (M): 1 / 1.5 / 2. Stop defines the required return-to-idle window before the next start edge.
  • Idle polarity / inversion: especially when UART is layered over RS-232 or through inverting transceivers.
  • Break semantics (if used): how long “dominant low” must persist to be treated as BREAK vs a valid start bit.
  • Inter-frame gap policy (if relevant): required idle time between frames (common in half-duplex layering such as RS-485).

Bring-up checks (verify structure before blaming noise/clock)

  • Capture a single character with a logic/protocol analyzer and confirm the field order: Start → N data bits → (Parity) → M stop bits.
  • If bytes are consistently “garbage,” check inversion/idle polarity first (common with RS-232 adapters).
  • If bytes look shifted by exactly one bit, verify parity enable/mode and data-bit count match on both ends.
  • Pass criteria (structure-level): analyzer decodes stable characters with the expected N/parity/M fields across a representative capture window (threshold X bytes).

Boundary rule: do not expand into baud-rate error math, noise filtering, or transceiver/ESD selection here. Keep this chapter purely about bit-structure contract and how to validate it.

UART frame format scope: stack and configuration knobs Diagram showing MCU UART, PHY/line, and peer UART blocks with must-match frame format knobs: data bits, parity, stop bits, idle polarity, and break detect. UART stack + frame format knobs (must match end-to-end) MCU / SoC UART Format config PHY / Line Level / invert / gap Peer UART Must match Frame format knobs (end-to-end contract) Data bits (N) 7 / 8 / 9 Parity N / E / O / M / S Stop bits (M) 1 / 1.5 / 2 Idle polarity / inversion Break detect Gap policy MUST MATCH

Frame anatomy: start bit → data bits → parity → stop bits → idle

Treat the UART frame as a bit-field template. Every debug step becomes easier when each decoded byte maps cleanly onto the same structure: Idle → Start → Data (LSB first) → (Parity) → Stop.

What each field means (structure-level, not math)

  • Idle: the line rests in the “mark” state between frames. If the idle level is inverted by an adapter, the receiver may never recognize a valid start edge.
  • Start bit: a transition from idle to the active state that allows the receiver to align sampling to a new frame. If the start edge is misinterpreted, all following bits shift.
  • Data bits (N): transmitted LSB first. A wrong data-bit count is one of the fastest ways to create repeatable “garbled” output that looks like a constant rotate/shift.
  • Parity (optional): a single structural bit appended after data bits. Any parity mismatch effectively inserts/removes one bit, causing consistent misalignment at the byte boundary.
  • Stop bits (M): a required return-to-idle window. More stop time can improve frame separation and give additional recovery margin for half-duplex layering, but it is not a substitute for correct structure matching.

Common misreads (fast diagnosis using the strip)

  • “Every byte is wrong”: check inversion/idle polarity and start-edge recognition before any deeper analysis.
  • “Bytes look shifted by 1 bit”: parity enabled on one side but disabled (or different mode) on the other is a top cause.
  • “Readable sometimes, then nonsense”: structure mismatch (N/parity/M) can appear intermittent when the analyzer auto-detects settings. Lock the analyzer’s decode parameters to the intended format and re-check.
  • “Stop looks too short”: confirm that the analyzer is decoding the correct baud and inversion; do not treat the display as ground truth without configuration.

Bring-up checks + pass criteria (structure-first)

  • Trigger on the start edge and verify the analyzer shows exactly N data bits, then optional parity, then M stop bits.
  • Confirm LSB-first ordering by sending a known pattern (e.g., 0x55/0xAA) and verifying bit alternation in the data field.
  • Pass criteria: a fixed capture of X frames decodes with consistent field boundaries and stable byte values under the intended format (no auto-detect “flips” in N/parity/M).
UART frame bit-field strip A labeled strip showing UART fields: Idle, Start, D0 to D7 data bits (LSB first), optional Parity, and Stop. UART frame anatomy (bit-field template) Idle Start D0 D7 LSB first (Parity) Stop Template: Idle → Start → Data → (Parity) → Stop Any mismatch shifts field boundaries Stop = return-to-idle

Data bits choices (5–9): payload, 9-bit address/data, ASCII vs binary

Data-bit count (N) defines the payload width of each UART character. A mismatch in N causes systematic boundary drift (bit-slip) at every character, even when the waveform looks stable.

Why “not always 8N1”

  • Legacy compatibility: 5/6-bit and 7-bit formats still appear in older instruments and terminals; modern endpoints may require matching these formats.
  • Text vs binary payload: 7-bit payload aligns with classic ASCII conventions, while 8-bit is safer for arbitrary binary data (0x00–0xFF).
  • Multiprocessor hooks: 9-bit framing can carry an address/data mark without changing the upper-layer packet format.

Practical selection logic (structure-level)

  • 7-bit payload: choose when endpoints explicitly specify 7-bit character framing (often paired with parity in legacy conventions).
  • 8-bit payload: default choice for modern UART links, especially for transparent binary transfer and mixed control/data bytes.
  • 9-bit payload: choose when the link requires an explicit address mark per character (multi-drop or multiprocessor framing), and confirm analyzer/tooling support for observing the 9th bit.

9-bit address/data concept (configuration hooks only)

In 9-bit framing, the extra bit is commonly used as an address/data mark: “address characters” assert the mark, while “data characters” deassert it. Receivers can filter based on the mark before accepting payload.

  • Confirm whether hardware supports true 9-bit data or a multiprocessor mode that treats the 9th bit as a mark.
  • Confirm how tooling represents the 9th bit (some analyzers show only 8-bit bytes unless explicitly configured).
  • Keep electrical multi-drop details out of this chapter; treat 9-bit as a frame-format hook.

Bring-up checks + pass criteria (bit-count sanity)

  • Lock the analyzer’s decode settings to the intended N/parity/stop and verify that field boundaries remain stable across a capture window.
  • Use known patterns (e.g., 0x55 / 0xAA) to visually confirm bit alternation in the data field; include 0x00 and 0xFF to check extremes.
  • Pass criteria: X frames decode with the expected N-bit payload and consistent byte boundaries (no recurring shift by ±1 bit).
UART data-bit width comparison: 7-bit, 8-bit, 9-bit Three aligned UART frame strips comparing 7-bit, 8-bit, and 9-bit data payloads with start, optional parity, and stop fields. Data-bit payload width (N): aligned strip comparison 7-bit 8-bit 9-bit Idle Start D0 D6 (Parity) Stop Idle Start D0 D7 (Parity) Stop Idle Start D0 D8 (Parity) Stop 9th bit can carry an address/data mark

Parity modes: none/even/odd/mark/space and what they really detect

Parity is a single structural bit appended after the data field. It provides limited error detection for certain bit-flip patterns, but it is not a CRC and does not guarantee integrity.

What parity detects (and what it does not)

  • Typically detects a single-bit flip (and other odd-count flips) within the protected data field.
  • May miss even-count flips (e.g., two bits flip in opposite directions), because overall parity can remain unchanged.
  • Does not replace packet-level checks (CRC/checksum). Keep packet integrity mechanisms out of this chapter.

Mode selection (why each mode exists)

  • None: simplest structure and maximum throughput (no parity bit).
  • Even / Odd: common compatibility choices for basic detection; requires exact mode matching end-to-end.
  • Mark: parity bit fixed to 1; used for legacy compatibility or as a flag in specific stacks.
  • Space: parity bit fixed to 0; similar compatibility/flag use.

Compatibility traps (structure drift vs “parity error”)

  • If parity is enabled on only one endpoint, the receiver may interpret the parity bit as part of the stop field (or the next start), causing recurring boundary errors.
  • Even vs odd mismatch often appears as “parity error on every byte” even when data bits are otherwise aligned.
  • Mark/space parity is frequently used for legacy conventions; treating it as even/odd can produce systematic decode failure.

Bring-up checks + pass criteria (parity sanity)

  • Set the analyzer decode mode explicitly to the intended parity type (do not rely on auto-detect).
  • Send repeated known patterns and verify that parity classification remains stable (no “all-bytes parity error” under correct configuration).
  • Pass criteria: parity error count stays below threshold X over a capture window of X frames, with stable byte boundaries.
Parity generation and mode selection Block diagram showing data bits feeding a parity generator, producing a parity bit, with selectable modes: None, Even, Odd, Mark, Space. Parity: data bits → generator → parity bit (mode selectable) Data bits D0 … D(N-1) Parity generator reduce / combine Parity bit 1 bit Mode None Even Odd Mark Space Parity is not CRC (packet-level)

Stop bits & sampling margin: 1 vs 1.5 vs 2, and when “extra stop” helps

Stop bits define the required return-to-idle window at the end of each UART character. They add recovery margin between frames and can increase tolerance to endpoint/bridge timing behavior, but they do not replace correct baud planning or noise robustness.

What stop bits buy (engineering meaning)

  • Frame recovery margin: a guaranteed idle interval that helps the receiver re-arm start-edge detection and cleanly close the prior frame.
  • System margin: extra idle time can reduce sensitivity to endpoint/bridge pacing (e.g., buffering jitter, byte spacing variation), and can create more comfortable turn-around timing in half-duplex layering (concept only).
  • Compatibility knob: some legacy endpoints explicitly require 1.5 or 2 stop bits; matching the spec avoids systematic framing failures.

1 vs 1.5 vs 2 (practical guidance)

  • 1 stop bit: highest throughput and the most common default. Use unless an endpoint spec or a system constraint suggests otherwise.
  • 1.5 stop bits: primarily a compatibility setting (often seen in older/legacy conventions). Use only when explicitly required.
  • 2 stop bits: increases inter-frame idle spacing and can help when byte spacing is irregular through bridges/adapters, or when a more generous return-to-idle window is needed for predictable frame separation.

What “extra stop” does NOT fix (keep scope clean)

  • Stop bits do not replace baud accuracy planning (handled in the baud error budget chapter).
  • Stop bits do not solve noise-induced sampling issues (handled in the framing/parity error chapter).
  • Stop bits do not compensate for electrical-layer integrity problems (handled in PHY/level topics).

Bring-up checks + pass criteria (stop-bit sanity)

  • Capture the same traffic with stop=1 and stop=2 (when both endpoints allow it) and compare frame boundary stability under the target workload.
  • Ensure both endpoints use the same stop setting; mismatched stop time is a direct cause of framing-related decode failures.
  • Pass criteria: X frames decode with stable boundaries at the intended stop setting, with framing anomalies below threshold X.
Stop bits comparison: 1 vs 1.5 vs 2 Three aligned UART frame strips showing stop region length differences for stop=1, stop=1.5, and stop=2. Stop region length = recovery margin (structure-level) Stop = 1 Stop = 1.5 Stop = 2 Idle Start Data (Parity) Stop Idle Start Data (Parity) Stop Idle Start Data (Parity) Stop Recovery margin

Idle polarity & inversion: why RS-232 feels “backwards”

UART framing assumes a logic-level convention where idle is “mark” (logic 1). When a physical layer maps logic levels with inversion, the receiver may fail to recognize valid start edges, causing “all-garbage” decoding even when baud and framing fields are otherwise correct.

Logic-level baseline (frame-format view)

  • Idle (mark) = logic 1 in typical UART conventions; the start bit is detected as a transition away from idle.
  • If idle polarity is interpreted incorrectly, the receiver may treat idle as an active start condition and never align sampling to valid frames.

Why RS-232 often looks inverted (concept only)

  • RS-232 physical mapping commonly inverts the logic sense compared to TTL/CMOS UART expectations.
  • The correct fix is aligning inversion/polarity across the chain (UART peripheral settings, adapters, or analyzer decode options), not altering packet formats or payload encoding.

Fast symptoms (diagnose inversion before deeper debugging)

  • All bytes are nonsense: inversion/idle polarity mismatch is a top suspect.
  • Receiver appears “always busy”: idle interpreted as active can prevent valid start-edge detection.
  • Analyzer decode changes if “invert” is toggled: strong confirmation of polarity mapping impact.

Bring-up checks + pass criteria (polarity sanity)

  • Observe the line during idle; confirm that the expected idle state is stable and that a start bit appears as a clear transition away from idle.
  • If decoding fails, toggle inversion at the correct layer (UART TX/RX invert option, adapter behavior, or analyzer decode inversion) and re-check frame detection.
  • Pass criteria: after correct inversion alignment, start-edge recognition is consistent and decoded characters remain stable over X frames.
UART logic vs RS-232 line polarity (concept-only) Two-column diagram comparing UART logic-level framing to RS-232 line polarity with an inversion mapping indicator. Idle polarity mapping: UART logic ↔ RS-232 line (inverted) UART logic Idle = mark (1) Start Idle RS-232 line often inverted Start Idle inverted Wrong inversion → no valid start edge → garbled bytes

Break, sync patterns, and “special symbols” (dominant low for N bit-times)

A break is not a “bad waveform” by default. It is a defined condition where the line stays at the start-bit polarity (typically dominant low) for longer than a normal character, allowing a receiver to raise a detectable event such as reset, wake, or re-synchronization hooks.

Definition (structure-level)

  • Normal character: start → data → (parity) → stop, then return to idle (mark).
  • Break: the line remains at dominant low for longer than one character frame time, so a valid stop/idle boundary is not observed.
  • Delimiter concept: a return to mark/idle after the long-low interval commonly separates break from the next start.

Typical uses (hooks, not full protocol specs)

  • Reset / resync hook: force receivers into a known state before normal characters resume.
  • Wake hook: a long-low event can be detected reliably by low-power monitoring logic.
  • Sync hook: break may precede a fixed sync pattern to help re-align decoding and boundaries.

Break vs fault-like “stuck low” (fast discrimination)

  • Looks like break: long low → clear return to idle (mark) → clean start edges and stable characters afterwards.
  • Looks like a fault: low never returns to a stable idle, or transitions are irregular without a consistent delimiter and follow-on frames.
  • Decode clue: continuous framing anomalies with no stable “mark” region suggests configuration/polarity mismatch or non-break faults.

Bring-up checks + pass criteria (break detect)

  • Capture idle → long-low → return-to-mark → subsequent characters; confirm the presence of a clear delimiter region.
  • Confirm the receiver exposes a break detect event (interrupt/flag) and that it triggers the intended hook (reset/wake/resync path).
  • Pass criteria: break detect triggers once per injected event and normal decoding resumes within X frames after the delimiter (threshold X).
UART break symbol: long low, delimiter mark, then normal frames A strip showing idle, a long-low break interval, a mark delimiter, then a normal start and data. A block indicates break detect generating events. Break = dominant low for N bit-times (event-capable symbol) Idle Break (long low) Mark Start Data Break detect duration threshold event generation Hook Reset Wake Resync Break is a defined symbol

Multiprocessor / multi-drop framing: 9-bit address mark + filtering concept

In a multi-drop topology, the key problem is not “can data be sent” but which node should pay attention. A common framing hook is 9-bit mode, where the 9th bit acts as an address mark that separates address/control characters from normal data characters.

Core mechanism (concept-level)

  • Address mark = 1: characters flagged as address/control.
  • Data mark = 0: characters treated as payload data.
  • Goal: enable receivers to filter and only “wake/accept” when an address mark matches.

Receiver filtering concept (state view)

  • Listen state: ignore data-mark characters; only evaluate address-mark characters.
  • Address match: enter Selected state and accept subsequent data-mark characters.
  • Address mismatch: remain in Listen state and discard the following data-mark stream.

Debug hooks (without electrical-layer details)

  • Ensure the analyzer can display the 9th bit; otherwise the address mark may be invisible during debug.
  • Confirm that address-mark characters appear at transaction boundaries (before data-mark bursts).
  • Keep bus biasing/termination/driver arbitration out of this chapter; treat multi-drop as a framing/selection concept.

Pass criteria (selection works)

  • Non-target nodes remain in Listen state and do not deliver payload to upper layers during other nodes’ transactions.
  • Target node enters Selected state on an address mark match and accepts the following data-mark burst.
  • Threshold: false-select rate below X per X transactions (placeholder X).
Multi-drop framing with 9-bit address mark and receiver filtering A master communicates with multiple slaves over a shared link. Address-mark characters select the target node; other nodes remain listening. 9-bit address mark enables selection on a shared multi-drop link Master TX/RX Address mark = 1 Data mark = 0 Slave A Listen Slave B Selected Slave C Listen Filter rule Listen: mark=1 Selected: mark=0 Framing selection (no PHY details)

LIN layering hooks: break + sync + ID, and what UART must expose

The LIN header can be viewed as three structure-level elements—Break, Sync, and ID. From a UART perspective, the goal is not to implement the full LIN stack here, but to ensure UART exposes the right configurable / detectable hooks so the header can be generated, detected, and verified reliably.

What the UART layer must provide (hook map)

  • Break: the ability to generate and/or detect a long-low break event (preferably via a break-detect flag/interrupt).
  • Sync: stable decoding of the sync byte as a normal UART character under the configured frame format.
  • ID: treated as UART framing payload; correct ID reception depends on data bits/parity/stop alignment, not “special LIN magic.”

Break-length and detect threshold (common pitfall, interface-level)

  • If break is too short, a break-detect engine may not trigger and the header start is missed.
  • If break handling lacks a clean return-to-mark delimiter, receivers may appear “always busy” or lose clean start-edge alignment.
  • Treat break threshold as a configuration/validation point; avoid embedding protocol-wide details in this chapter.

Debug and verification (structure-first)

  • Verify the sequence Break → Sync → ID with a logic/protocol analyzer view.
  • Confirm break detect triggers as an event (or can be inferred reliably), then confirm Sync and ID decode as normal UART bytes.
  • If ID is garbled, prioritize frame-format alignment (data bits/parity/stop) and polarity/inversion sanity before deeper stack work.

Pass criteria (LIN header hooks are healthy)

  • Break detect triggers once per injected header and does not “stick” across multiple frames.
  • Sync and ID decode consistently over X headers under intended load and timing (threshold X).
  • A clear mark delimiter exists between break and the first start edge of the following bytes.
LIN header: Break, Sync, and ID with UART configuration hooks A strip shows LIN header elements Break, Sync, and ID. A side box lists UART hooks such as break detect and frame format settings. LIN header view (UART hooks focus): Break | Sync | ID Break Sync ID break threshold UART hooks break detect break generate 8 data parity mode

RS-485 layering hooks: half-duplex turn-around, DE control, and frame gaps

On half-duplex links, direction switching is a timing problem: the driver-enable window must cover the entire UART frame, then release the line with enough guard time and idle gap for safe turn-around. This chapter stays at the layering level and avoids electrical termination/bias details.

Why gaps matter (half-duplex model)

  • TX and RX share the same medium; switching requires a non-zero window to avoid truncation and collisions.
  • The effective “end of frame” is not just the last data bit; it includes stop/idle behavior and end-of-drive timing.
  • Frame gaps provide a controllable boundary that upper layers can use to schedule safe turn-around.

DE control window (frame coverage + guard time)

  • DE=1 must cover: Start → Data → (Parity) → Stop.
  • Guard time: keep DE asserted slightly beyond the last stop boundary to avoid tail-bit truncation.
  • After DE deasserts, reserve an idle gap before expecting valid RX (turn-around window).

Stop bits and idle gaps (layering leverage)

  • Stop bits extend the return-to-idle window at the end of each character, improving timing clarity for end-of-frame handling.
  • An explicit idle gap between TX and RX phases reduces accidental overlap and makes scheduling deterministic.
  • This is a timing/behavior hook; it is not a substitute for electrical-layer correctness.

Bring-up checks + pass criteria (turn-around)

  • Observe TXD, DE, and the receive window timing; ensure DE stays asserted through stop and does not drop early.
  • Verify a consistent gap exists before switching into RX; shorten only after confirming no truncation/collision symptoms.
  • Pass criteria: no tail-bit truncation, stable turn-around, and collision/redo rate below threshold X.
Half-duplex timing: DE covers the frame, then guard time and gap before RX A three-lane timing diagram shows a UART frame strip, a DE enable window covering the frame plus guard time, and a gap before RX phase begins. TX → gap → RX: DE window must cover the full frame + guard time UART frame DE RX Start Data (Parity) Stop DE = 1 guard time gap listen (RX) early DE off → tail-bit truncation

RS-232 layering hooks: framing stays, electrical does not — what to verify first

UART frame format (start/data/parity/stop/idle) remains the same across PHY choices. When a design “works on TTL UART” but fails after adding RS-232, the fastest diagnosis is to confirm framing at the UART pins first, then validate polarity mapping and reference behavior at the PHY boundary.

Layering map: what stays vs what changes

Stays (UART framing)
  • Data bits / parity / stop bits
  • Idle meaning (mark) and break handling (if used)
  • Byte decode expectations and error flags (framing/parity)
Changes (PHY mapping)
  • Polarity inversion (common root cause of “all wrong bytes”)
  • Logic-to-line conversion behavior (boundary check, not full PHY theory)
  • Reference exposure (ground/reference becomes visible through cabling/adapters)

Verify in this order (fastest isolation)

  1. Prove UART framing at MCU pins: decode TX as the expected bytes under the intended frame format profile.
  2. Check inversion/polarity mapping: if decode fails only after the RS-232 stage, inversion is the first suspect.
  3. Reference check (second priority): if inversion is correct but errors persist, treat reference/adapter effects as the next checkpoint.

Example PHY parts to validate “same framing, different electrical” (verify package/suffix)

RS-232 transceivers (TTL UART ↔ RS-232 line)
  • TI TRS3232E — widely used RS-232 level shifter family
  • Maxim (Analog Devices) MAX3232 — classic 3.3 V RS-232 transceiver
  • Sipex/Exar (MaxLinear) SP3232E — common MAX3232-compatible option
  • Analog Devices ADM3202 — RS-232 transceiver family option
Scope note: selection here is only to illustrate PHY mapping changes; detailed electrical constraints belong in the PHY subpage.
RS-485 transceivers (for contrast in the diagram)
  • TI SN65HVD72 — common half-duplex RS-485/RS-422 transceiver family
  • Maxim (Analog Devices) MAX3485 — widely used RS-485 transceiver
  • Analog Devices ADM485 — popular RS-485 transceiver family

Pass criteria (layering sanity)

  • MCU UART pins decode stable for X frames under the intended frame format (threshold X).
  • After RS-232 conversion, the same traffic decodes without persistent framing/parity anomalies (threshold X).
  • If an “invert decode” switch instantly fixes decode, polarity mapping is confirmed as the first-order root cause.
Same UART frame, different PHY blocks: LVCMOS vs RS-232 vs RS-485 A UART frame strip feeds three PHY blocks in parallel, emphasizing framing consistency and PHY mapping differences such as inversion and reference checks. Same framing, different electrical mapping (verify inversion first) UART frame Start Data (Parity) Stop LVCMOS logic levels RS-232 inverted ref check RS-485 half-duplex framing stays

Engineering checklist (design → bring-up → production) for frame format

Frame format becomes production-safe only when it is treated as a gated workflow: define a system profile, verify with repeatable instrumentation, and lock down configuration with readback and misconfiguration detection.

Design gate (system profile definition)

  • Default profile: document 8N1 / 7E1 / 9-bit rules and where exceptions are permitted.
  • Inversion policy: allow polarity inversion at only one layer (UART IP or PHY), never both.
  • Break/idle policy: define break usage (if any) and the required delimiter/idle gap behavior.
  • Pass criteria: every endpoint can state the same profile unambiguously and can be verified by readback.

Bring-up gate (repeatable capture + loopback)

  • Analyzer template: triggers for start edge, stop width, parity flag, and break event (if used).
  • Loopback: run internal/external loopback to validate data/parity/stop and inversion mapping quickly.
  • Test vectors (structure-revealing): 0x00 / 0xFF / 0x55 / 0xAA to expose bit order and polarity issues.
  • Pass criteria: X consecutive frames decode correctly with zero persistent framing/parity anomalies (threshold X).

Production gate (readback, misconfig detection, fallback)

  • Config readback: verify data/parity/stop/inversion/break-detect enable matches the golden profile at boot.
  • Misconfig detection: detect “silent wrong framing” by injecting known frames and checking error statistics.
  • Fallback policy: defined downgrade/recovery path (e.g., revert to default profile) without infinite reset loops.
  • Pass criteria: misconfig is detected within X seconds and recorded with the active profile snapshot (threshold X).

Practical bring-up materials (examples; verify availability and variants)

  • Logic analyzer: Saleae Logic Pro 8 / Logic Pro 16 (UART decode + triggers)
  • USB–UART bridge (test endpoint): FTDI FT232R modules or Silicon Labs CP2102N based adapters
  • RS-232 test stage: TI TRS3232E breakout or MAX MAX3232 based boards for polarity sanity checks
  • RS-485 turn-around stage (for layered validation): MAX MAX3485 or TI SN65HVD72 breakouts when half-duplex timing is under test
Engineering gates for frame format: Design, Bring-up, Production A pipeline diagram shows three gates with check blocks: design profile, bring-up capture and loopback, and production readback and misconfig detection. Gated workflow: Design → Bring-up → Production (frame format) Design Bring-up Production Default profile Inversion policy Break/Idle rule Pass criteria Trigger template Loopback Vectors Pass criteria Readback Misconfig detect Fallback Pass criteria

Request a Quote

Accepted Formats

pdf, csv, xls, xlsx, zip

Attachment

Drag & drop files here or use the button below.

FAQs: UART frame format troubleshooting (data bits, parity, stop, idle/inversion, break, multi-drop)

Each answer is a minimal, execution-focused checklist: Likely causeQuick checkFixPass criteria (threshold placeholders X/Y/T).

Two devices both claim 8N1, but bytes look shifted by 1 bit.
Likely cause: start-bit polarity/inversion mismatch, or wrong word length (7/8/9-bit) on one side.
Quick check: enable “invert decode” in the analyzer; read back UART word-length/invert/parity/stop settings on both endpoints.
Fix: apply inversion at exactly one layer (UART IP or PHY) and align word length to the same data-bit setting end-to-end.
Pass criteria: X consecutive frames decode correctly with framing error counter = 0 (threshold X).
Works for ASCII but fails for binary frames.
Likely cause: 7-bit framing or MSB masking; parity/translation layers stripping or modifying non-printable bytes.
Quick check: send test vectors 0x00 / 0xFF / 0x55 / 0xAA and verify the received byte values match exactly (no MSB loss).
Fix: force 8 data bits for binary transport; disable any “7-bit/ASCII-only” assumptions and parity stripping in the path.
Pass criteria: all four vectors are received byte-exact over X frames; parity/framing error counters remain 0.
Parity errors spike only on certain byte values.
Likely cause: parity mode mismatch (even/odd/mark/space) or parity enabled on only one endpoint.
Quick check: read back parity mode on both ends; compare analyzer parity setting to the actual hardware configuration.
Fix: set the same parity mode end-to-end (or disable parity on both ends) and retest with full byte-range traffic.
Pass criteria: parity error counter stays at 0 across X frames including worst-case byte patterns (threshold X).
Stop bit seems “too short” on the analyzer.
Likely cause: decode/measurement setup artifact (wrong baud or sampling) or actual stop-bit mismatch (1 vs 2).
Quick check: measure bit-time from the waveform and ensure analyzer baud matches; verify stop-bit setting via UART register readback.
Fix: correct analyzer decode parameters and align stop-bit configuration on both endpoints (1 / 1.5 / 2 as supported).
Pass criteria: measured stop duration is ≥ configured stop in bit-times within ±T tolerance (threshold T).
RS-232 adapter makes everything unreadable.
Likely cause: inversion/idle polarity mismatch at the RS-232 mapping boundary (framing stays; electrical polarity often flips).
Quick check: toggle “invert decode” in the analyzer; confirm the idle state matches expectations and that TX/RX are not swapped.
Fix: apply inversion at exactly one point (UART IP or transceiver) and standardize the endpoint configuration.
Pass criteria: X consecutive frames decode correctly with framing/parity error counters = 0 (threshold X).
RS-485 half-duplex misses the first byte after direction change.
Likely cause: DE turn-around timing too tight (no guard time/gap); receiver is enabled late or line is released early.
Quick check: capture TXD + DE + RX with a logic analyzer; verify DE stays asserted through stop and releases after a guard window.
Fix: extend DE guard time after the last stop boundary and insert an explicit idle gap before enabling RX.
Pass criteria: no missing first byte across X turn-arounds; retry/collision counters remain below threshold X.
LIN break is not detected reliably.
Likely cause: break detect not enabled, break threshold/length mismatch, or missing mark delimiter between break and following bytes.
Quick check: confirm break-detect flag/interrupt toggles; measure break low duration in bit-times; verify delimiter mark exists.
Fix: enable break detect, ensure break exceeds the configured threshold, and enforce a clean return-to-mark before start-bit activity.
Pass criteria: break detect fires 1:1 with injected breaks over X trials (threshold X).
9-bit multi-drop: all nodes respond to the same command.
Likely cause: 9th-bit address mark is not used consistently, or receivers do not filter/wake only on address-marked bytes.
Quick check: verify the 9th bit is set only on address bytes; confirm receiver “multiprocessor/9-bit filter” mode is enabled.
Fix: enforce address-mark framing (9th bit = 1 for address, 0 for data) and gate reception until a matching address is seen.
Pass criteria: only the addressed node responds across X address cycles; non-addressed nodes stay silent (threshold X).
One side sends 7E1 and the other is 8N1 — why does it sometimes “kind of work”?
Likely cause: framing ambiguity: the receiver may occasionally interpret parity/stop timing as data boundaries for “friendly” byte patterns.
Quick check: transmit a mixed pattern set (0x00/0xFF/0x55/0xAA) and compare bit-level boundaries; watch framing/parity flags.
Fix: align word length and parity explicitly; do not rely on “sometimes” decodes for production behavior.
Pass criteria: X frames decode byte-exact with framing/parity error counters = 0 (threshold X).
After reset, the first frame is always corrupted.
Likely cause: line idle is not stable at bring-up, or a false start-bit trigger occurs before the receiver state machine is ready.
Quick check: delay the first TX by Y bit-times after reset; flush RX FIFO; verify idle level is stable before the first start edge.
Fix: enforce an idle settle window, clear error flags/FIFOs after reset, and only then send the first framed byte.
Pass criteria: the first frame decodes correctly across X resets; no persistent framing errors observed (threshold X).
Changing stop bits reduced overruns — why?
Likely cause: extra stop/idle time increased service margin (ISR/DMA latency window), not a baud error “fix.”
Quick check: compare overrun flag/counter rates for stop=1 vs stop=2 under the same throughput and interrupt load.
Fix: increase stop bits or insert inter-byte gaps; alternatively reduce interrupt load or use DMA to meet worst-case servicing.
Pass criteria: overrun counter remains 0 for Y seconds at target throughput; error counters stay below threshold X.
Mark/Space parity: when would it ever be used?
Likely cause: legacy/compatibility framing uses a fixed parity bit as a marker (a “flag bit”), not as error detection.
Quick check: confirm the peer expects mark/space as a symbol marker; verify the receiver does not treat it as even/odd parity.
Fix: set mark/space parity only when a legacy peer/protocol explicitly requires a constant marker bit and document the mapping.
Pass criteria: marker behavior matches spec over X frames; payload bytes remain unchanged and framing errors stay at 0.