SPI, I2C, and UART Interview Questions: Timing, Buses, and Debugging

SPI, I2C, and UART interview questions test whether you can connect a protocol description to a signal on a board. The useful answer explains timing, electrical assumptions, framing, and the next measurement. Memorizing that SPI is fast, I2C uses two wires, and UART has no clock does not diagnose a device that returns the wrong byte.

This guide uses conventional four-wire SPI, common bidirectional I2C modes, and logic-level UART with an 8N1 example. Specific devices can add restrictions or variants, so their datasheets control the final design. The waveforms and fault scenarios are original teaching examples, not captures from a particular product.

Here, we focus on reading the bus and choosing the next safe diagnostic step.

How should I compare SPI, I2C, and UART?

Start with the physical and timing model. SPI normally uses a controller-generated clock and device-select signal. I2C combines addressing and acknowledgments on shared clock/data lines. UART uses agreed timing and framing without a shared clock wire.

Property	SPI, conventional four-wire	I2C, common bidirectional modes	Logic-level UART
Timing	Shared serial clock	Shared SCL, with protocol timing rules	Independent clocks at agreed baud
Selection	Typically chip-select per target	Address carried in transfer	Usually point-to-point link
Data signals	MOSI and MISO	Shared SDA	TX and RX
Common electrical concern	Edge timing and signal integrity	Pull-ups, rise time, capacitance	Voltage compatibility and baud error
Useful first capture	CS, SCLK, MOSI, MISO	SCL and SDA	TX/RX with known framing

The table omits ground and power from signal counts. That omission should never imply that unrelated grounds or incompatible voltage domains are safe. Check electrical compatibility before connecting instruments or interfaces.

There is no universal best protocol. A sensor's supported interface, board pin budget, throughput, distance, power, and topology constrain the choice. Say which requirement drives your recommendation and which trade-off remains.

What do CPOL and CPHA mean in SPI?

CPOL defines the clock's idle level. CPHA determines whether data is sampled on the leading or trailing edge relative to the start of a clock cycle. The actual rising or falling edge therefore depends on both settings.

For conventional mode 0, CPOL is zero and CPHA is zero: clock idles low and data is sampled on the leading rising edge. The transmitting side changes subsequent bits on the opposite edge so the receiver has a valid sampling window. Other modes change that relationship.

Do not answer only with a mode number. A datasheet may describe sampling and shifting edges directly, and a controller API may use different naming conventions. Translate both sides into idle level, sample edge, setup time, and hold time.

Also check bit order, word length, clock frequency, chip-select polarity, and whether chip select must remain asserted across a command and response. A one-byte shift can come from framing or dummy clocks, not only from CPHA.

Can you decode a mode-0 SPI byte?

Use an original eight-bit example with MSB-first transmission of hexadecimal A5. Its bit sequence is 1 0 1 0 0 1 0 1. With CS active and mode-0 timing, inspect MOSI at each of eight rising clock edges.

If you instead sample at the edges where data changes, a digital decoder may display unstable or shifted results depending on timing. The waveform should show data settled before the intended edge and held afterward. A decoded label alone does not prove those margins are healthy.

Now imagine the target returns valid data only after a command byte and two dummy bytes. Capturing the first eight MISO clocks and expecting the payload is a protocol mistake, not necessarily an electrical failure. Read the transaction format before changing clock polarity.

For an interview follow-up, halve the clock rate. If the issue disappears, you have evidence consistent with a timing or signal-integrity margin problem, but not proof of one exact cause. Check rise/fall times, trace loading, setup/hold requirements, and the controller's actual clock setting.

How do I2C addressing and acknowledgments work?

In a common seven-bit I2C transaction, the address is followed by a read/write bit. Each transferred byte is followed by an acknowledgment bit. A START condition begins the transaction; STOP ends it, while a repeated START can continue a combined operation without releasing the bus in the same way.

An address convention is a frequent interview trap. If a datasheet gives seven-bit address 0x50, the first address byte on the wire is 0xA0 for a write or 0xA1 for a read. Some software APIs expect the seven-bit value; others expose a shifted representation. Check the API rather than shifting twice.

An ACK indicates that the receiver pulled SDA low during the acknowledgment clock. It is not a universal guarantee that the entire requested application operation has completed successfully. Device-specific status and timing still matter.

For a register read, many devices expect address-write, register index, repeated START, address-read, data, then a final NACK and STOP from the controller. That is a common pattern, not a replacement for the target's datasheet. Some devices use different command formats.

Why do I2C pull-ups and rise time matter?

Common bidirectional I2C modes use open-drain or open-collector signaling: participants pull a line low or release it, while pull-ups bring it high. The rising edge depends on resistance and bus capacitance, so a digital high is not an instantaneous event.

A weak pull-up can produce slow rising edges that violate the timing budget. An excessively strong pull-up increases the current a device must sink when driving low. Choose from the bus mode, voltage, capacitance, and device limits, not a universal resistor value copied from another board.

Clock stretching is another timing consideration: a target may hold SCL low in supported situations. The controller must handle the target's documented behavior. A timeout can indicate legitimate stretching, a stuck device, wiring trouble, or an unsupported controller configuration.

Use an oscilloscope when edge shape and voltage margins are the question. A logic analyzer is excellent for sequence and decoding, but a clean decoded address can coexist with poor analog margins. Explain which instrument answers which hypothesis.

How do I debug an I2C NACK or a stuck-low bus?

First identify where the NACK occurs: address, register byte, or data byte. Address NACK suggests a different investigation from a device rejecting a command after acknowledging its address. Record the exact transaction rather than summarizing everything as "I2C failed."

Check power, reset, address pins, voltage levels, pull-ups, and the seven-bit versus shifted-address convention. Then verify the device's readiness delay and supported bus speed. Do not change several settings at once or you will lose the evidence that distinguishes causes.

For a stuck-low line, inspect which participant or fault is holding it. Recovery may involve a device-specific reset or a protocol-defined bus-clear procedure under suitable conditions, but it should not be presented as a blind sequence safe for every board. Understand what is connected and what a reset would disrupt.

An original diagnostic exercise: the address ACKs at 100 kHz but intermittently fails at 400 kHz. Your next step should examine timing margins and rise time alongside device support, not immediately rewrite the register map. A change in failure with speed is a clue, not a complete diagnosis.

What does UART 8N1 actually mean?

8N1 means eight data bits, no parity bit, and one stop bit. A conventional frame also has one start bit, so ten transmitted bit periods carry eight payload bits. UART uses local timing on both ends; there is no shared clock line to correct the receiver continuously.

At 115200 bits per second, one bit lasts approximately 8.68 microseconds. An 8N1 character occupies about 86.8 microseconds, giving a theoretical maximum of 11520 payload bytes per second before application gaps or additional protocol overhead.

That is an original calculation from the framing contract, not a benchmark. A device that pauses between characters, uses flow control, or wraps bytes in packets will deliver less application throughput.

Logic-level UART is not the same electrical interface as RS-232. Voltage levels and polarity can differ, and appropriate transceivers may be required. Confirm both sides before wiring TX to RX. The familiar UART framing does not make incompatible voltage standards safe.

Why does a UART terminal show garbage characters?

Check baud rate, data bits, parity, stop bits, signal polarity, ground reference, and voltage compatibility. Also verify pin routing and whether hardware flow control is enabled. A stopped stream can be a flow-control problem rather than a baud mismatch.

Send a known repeating pattern, such as 0x55, in a controlled test. Its alternating bits make timing easier to inspect. Measure a bit period on the waveform and compare it with the configured rate. A decoder configured with the same wrong assumption as your software can give a misleading picture.

Framing errors occur when expected framing conditions are not observed, such as an invalid stop-bit level. Parity detects only certain error patterns and is not a complete integrity check. Do not say a matching parity bit proves the payload is correct.

If corruption appears only under load, examine receiver overruns, interrupt latency, DMA configuration, buffer capacity, and consumer throughput. A correct wire-level frame can still be dropped by software that cannot drain the receive path quickly enough.

How should I choose the next measurement?

Translate the symptom into two or three competing hypotheses, then select a measurement that separates them. "Wrong SPI byte" might mean wrong sample edge, incorrect bit order, or reading during the command phase. One complete transaction capture can distinguish these more effectively than random register changes.

"I2C device missing" might mean wrong address convention, target held in reset, or an electrical line problem. Inspect address bits and ACK timing while checking reset and power. "UART stops after a burst" might mean flow control, buffer overrun, or application framing, so inspect both line activity and receiver status.

Preserve the original configuration and make one reversible change at a time. Record the predicted effect before the test. If reducing clock speed helps, note that evidence without jumping to a unique root cause.

Also describe safe instrument setup. Use suitable probes, voltage ranges, and ground connections for the board. In a real lab, follow the device and equipment procedures rather than treating a software interview guide as electrical safety authorization.

What should I practice before an embedded interview?

Prepare three small artifacts: an SPI sample-edge trace, an I2C register-read transaction with the address convention stated, and a UART payload-rate calculation. Explain each without relying on a decoder's labels.

Then rehearse one fault per protocol. For SPI, choose a wrong phase or missing dummy clocks. For I2C, choose an address NACK or slow rise time. For UART, choose a framing mismatch or receiver overrun. State the next observation and what result would change your hypothesis.

Finish by linking the bus to software ownership: who starts the transfer, who knows it completed, where data is buffered, and how timeouts are reported. A strong answer moves from protocol rule to waveform to evidence-backed action.

Sources and Further Reading

Checked September 23, 2026. The I2C reference is NXP revision 7.0; actual devices and controller APIs can impose narrower constraints.

• NXP: I2C-bus specification and user manual, revision 7.0
• Analog Devices: introduction to the SPI interface
• Analog Devices: UART framing and operation