Interface Protocols · All levels
UART Flow Control: Debug Playbook
Debug Playbook for UART Flow Control.
Debug playbook
Debug Playbook for UART Flow Control focuses on overrun count, baud mismatch, interrupt service latency. The goal is to connect the observable symptom to protocol mechanism, ownership, and regression risk.
Protocol debug is a search for the FIRST deviation, not the loudest symptom. Timeouts and error flags are usually many cycles downstream of the real cause.
Root-cause tree
ROOT-CAUSE TREE — UART Flow Control
overrun count, baud mismatch, interrupt service latency looks wrong
|
reproducible?
/ \
no yes
| |
flaky env same first transaction every time?
/ seed / \
yes no
| |
protocol rule timing/reset/PVT
or config bug or load-dependentFreeze the failing seed, firmware tag, and spec revision.
Find the first bad transaction, not the loudest downstream timeout.
Map the transaction to signals and VIP monitor events.
Classify the failure: protocol rule, integration config, timing/reset, or performance pressure.
Prove the mechanism with one reduced sequence.
Patch the smallest owner-controlled boundary and rerun compliance plus workload traffic.
Review memo template
STAFF PROTOCOL REVIEW MEMO — Embedded Peripherals (I2C / SPI / UART) / UART Flow Control
1. Symptom
- Watched metric: overrun count, baud mismatch, interrupt service latency
- Failing interface: <master/slave/endpoint/controller/PHY>
- Transaction identity: <ID/tag/address/endpoint/lane>
- Repro setup: <sim/emulation/FPGA/silicon + firmware tag>
2. Mechanism hypothesis
- Primary mechanism: UART converts bytes to asynchronous serial frames and depends on baud tolerance, FIFO depth, and flow control.
- Competing hypothesis: <timing, reset, bridge, ordering, firmware, or VIP issue>
- Missing evidence: <waveform, analyzer trace, counter, spec clause, or log>
3. Proposed action
- Minimal reversible change: <RTL, register setting, bridge config, scheduler, VIP check>
- Expected metric movement: <delta and workload>
- Regression risk: ordering, compatibility, performance, power, area, or timing
4. Signoff
- Re-run artifact: RX/TX waveform, FIFO watermark log, driver ISR trace
- Required owners: firmware owner, peripheral RTL owner, validation owner
- Final decision: fix, waive, document limitation, or escalate to architectureProtocol deep dive
I2C/SPI/UART bugs are contract bugs: timing, reset value, IRQ type, and DMA watermark.
Concept diagram
PERIPHERAL CONTRACT
firmware writes regs -> RTL state machine -> pins -> board -> device
^ |
+------- IRQ/DMA ----+
If IRQ is level but driver assumes edge, you get lost events.Metric graph
FIFO WATERMARK vs DMA
FIFO fill
100%| *** overrun risk
75%| ***
50%| *** <- ideal DMA trigger band
25%| *
0%+----------------> timeMetrics and artifacts to collect
NACK rate
overrun count
CS setup/hold violations
IRQ miss rate
Mini case study
SPI flash worked in loopback but failed in system: CS deasserted one cycle early relative to device hold time. Board + RTL + mode bits together formed the contract.
Debug branches
If overrun, FIFO depth vs ISR latency vs DMA burst.
If NACK on I2C, pull-ups, speed, and clock stretch.
If garbage data, CPOL/CPHA and MSB/LSB first.
Senior review question
Ask: what is the first transaction that deviates, and which spec rule does it test?
Key takeaways
Connect every protocol claim to a transaction identity and measurable metric.
Store the artifact (waveform, log, counter) next to every signoff decision.
Common pitfalls
Debugging timeouts without finding the first bad transaction.
Quoting peak bus width without payload efficiency and retry overhead.
Treating VIP compliance as a substitute for system integration replay.
Principal review addendum
Re-read UART Flow Control against one concrete product workload, not a synthetic directed test.
UART converts bytes to asynchronous serial frames and depends on baud tolerance, FIFO depth, and flow control.