A logic analyzer is one of the fastest ways to debug a digital interface because it shows what the pins actually did, not what the firmware intended to do. But a protocol decoder alone is not enough. If you capture at the wrong sample rate, use an incompatible voltage threshold, miss the ground reference, or trust decoded text without checking the waveform, the tool can mislead you.
The reliable workflow is: verify electrical compatibility, capture the raw signals with enough timing resolution, identify the transaction boundaries, then use a protocol decoder as a second layer of interpretation.
What a logic analyzer can and cannot tell you
A digital logic analyzer compares the input voltage against a threshold and records a sequence of logic 0s and 1s. It is excellent for:
- UART framing and baud-rate problems.
- I2C addresses, ACK/NACK behavior and clock timing.
- SPI chip-select, clock polarity/phase and byte ordering.
- GPIO timing between interrupts, sensors and control signals.
- Finding missing pulses, unexpected retries and task-latency problems.
It does not replace an oscilloscope for analog signal integrity. A logic analyzer may show a clean digital edge even when the real waveform has ringing, slow rise time or marginal amplitude. When the digital capture looks suspicious, inspect the same node with an oscilloscope.
1. Connect ground first
The analyzer and target need a common voltage reference. Connect the analyzer ground to the target ground before probing signals. Keep the ground path short when timing is fast.
A long ground lead can add inductance and make fast transitions look worse than they are. It can also increase susceptibility to noise.
2. Verify voltage compatibility before connecting
Do not assume every logic analyzer input is safe for every bus. Check the analyzer’s supported input range and logic thresholds.
Saleae, for example, documents different voltage limits and threshold behavior across its models. Some models provide selectable digital thresholds; others use fixed thresholds. High-voltage interfaces such as RS-232 may require different handling depending on the analyzer.
A decoder cannot fix an electrical mismatch. If the analyzer never sees a valid HIGH or LOW, the decoded protocol will be wrong.
3. Choose a sample rate based on the fastest edge you need to resolve
The sample rate determines how often the analyzer records the digital state. Capturing a 1 MHz clock at barely above 1 MS/s is not enough to reconstruct its timing reliably.
Use a sample rate several times higher than the signal rate so each bit or clock period contains multiple samples. The exact margin depends on the protocol, timing accuracy you need and the analyzer architecture.
Saleae’s documentation emphasizes that inadequate sampling bandwidth can make captured data incorrect. If you are investigating short glitches or setup/hold timing, increase the sample rate further.
4. Capture raw signals before enabling every decoder
First identify the physical channels:
- UART: TX and optionally RX.
- I2C: SDA and SCL.
- SPI: SCLK, MOSI, MISO and CS.
- Custom synchronous interface: clock plus relevant data/control lines.
Capture one known transaction and verify that transitions appear where you expect them. Only then configure the protocol analyzer.
UART: find framing errors systematically
For UART, start with the idle state and bit timing. A typical UART frame contains a start bit, data bits, optional parity and stop bit(s), but the exact configuration must match both endpoints.
If text is garbage, measure one bit period from the waveform and compare it with the configured baud rate. Then check:
- Data bits.
- Parity.
- Stop bits.
- Signal polarity/inversion.
- Whether you are probing the correct TX/RX line.
A common error is assuming the configured baud rate is what the pin actually produces. Clock configuration mistakes can shift UART timing enough to corrupt communication.
I2C: look beyond the address
I2C uses open-drain/open-collector signaling with pull-up resistors. The NXP I2C specification defines START and STOP conditions, address/data transfers and ACK/NACK behavior.
When an I2C device does not respond, inspect:
- Does SDA fall while SCL is HIGH to create a START?
- Is the expected address transmitted?
- Does the receiver pull SDA LOW during the ACK clock?
- Are SCL and SDA returning HIGH quickly enough?
- Does clock stretching occur?
- Is the controller repeatedly retrying after NACK?
A logic analyzer can show protocol timing, but an oscilloscope is better for measuring actual rise time when pull-ups, bus capacitance or long wiring are suspected.
SPI: timing is usually about four signals, not three
SPI debugging requires SCLK, data and chip select. Capturing MOSI/MISO without CS can make transactions difficult to separate.
If the decoded bytes are shifted or wrong, verify:
- Clock polarity (CPOL).
- Clock phase (CPHA).
- Bit order.
- Word length.
- Chip-select active level.
- Whether CS changes at the boundaries the peripheral datasheet requires.
Do not guess the mode from a library example. Compare the waveform with the peripheral datasheet.
Use the datasheet to measure setup and hold timing
A decoder may report correct bytes while the design still has little timing margin. If failures appear only at high clock rate, long cable length or temperature extremes, measure the timing relationships specified by the device:
- Data setup before the sampling edge.
- Data hold after the edge.
- CS setup/hold.
- Minimum HIGH and LOW clock times.
This is where a logic analyzer with adequate timing resolution becomes more useful than simply reading decoded hexadecimal values.
Trigger on the event that matters
Long captures create too much data. Use a trigger or capture condition around the failure:
- A rising/falling edge on an error pin.
- Chip select becoming active.
- A UART break or transaction start.
- A GPIO toggled by firmware immediately before the suspicious code path.
Adding a temporary debug GPIO is a powerful technique. Toggle it around an ISR, DMA completion or task section, then capture it beside the bus signals. You can directly correlate software timing with external communication.
Do not trust protocol decode without checking the waveform
Protocol decoders are convenience tools. They depend on your configuration and the captured samples. If the decoder says an I2C address is wrong, first check whether the analyzer threshold and sample rate are correct.
When debugging a difficult failure, inspect both levels:
- Physical capture: what transitions were recorded?
- Protocol interpretation: what bytes/frames do those transitions represent?
Glitches can be real—or measurement artifacts
Saleae documents that crosstalk between probe leads can create narrow pulses in neighboring channels. If a suspicious glitch lines up exactly with a transition on another probe, separate the leads and repeat the capture.
Also compare the digital capture with an analog/oscilloscope measurement when possible. A threshold crossing caused by ringing can appear as a legitimate digital transition even though the root cause is signal integrity.
USB and other differential high-speed buses need special care
The phrase “any digital bus” has limits. Standard USB signaling is differential, and high-speed USB has physical-layer requirements that a basic single-ended logic analyzer is not designed to measure directly.
USB-IF publishes dedicated electrical compliance specifications for USB. For low-level USB physical-layer debugging, use tools and probes intended for that bus. A logic analyzer can still be useful on higher-level control signals around a USB subsystem, but do not treat it as a universal USB electrical analyzer.
A repeatable 10-minute debug workflow
- Read the target interface voltage and timing requirements.
- Confirm analyzer voltage range and threshold compatibility.
- Connect ground and the minimum required signals.
- Set a conservative high sample rate.
- Capture one known transaction.
- Verify raw clock/data edges before decoding.
- Configure the protocol analyzer from the datasheet.
- Compare the decoded transaction with what firmware expected.
- Measure timing around the first incorrect event.
- If the digital waveform is marginal, switch to an oscilloscope.
Related interface troubleshooting
If the waveform shows an electrical or timing error, continue with our guide to wiring and timing mistakes that break microcontroller interfaces. For protocol selection, see UART vs I2C vs SPI vs USB.
Primary references
- Saleae: How to use a logic analyzer
- Saleae: Troubleshooting incorrect captures
- NXP UM10204: I2C-bus specification and user manual
- USB-IF: USB 2.0 Specification
Bottom line
A logic analyzer is most useful when you treat it as a timing instrument first and a protocol decoder second. Verify voltage levels, sample fast enough, inspect raw edges, then decode. That workflow turns “the bus is broken” into a specific electrical, timing or protocol failure you can actually fix.