MIPI I3C Protocol Analysis: Capturing and Debugging Next-Gen Sensor Buses

I3C vs I2C: What Changed and Why It Matters

MIPI I3C was designed as a direct successor to I2C, addressing the limitations that became apparent as sensor counts and data rates increased in mobile, IoT, and automotive systems. The key differences are substantial.

Speed: I2C tops out at 3.4 MHz in high-speed mode (and most implementations use 400 kHz or 1 MHz). I3C SDR (Single Data Rate) mode runs at up to 12.5 MHz, and HDR (High Data Rate) modes push effective throughput to 25 Mbps or higher.

Interrupt mechanism: I2C has no standard interrupt mechanism — devices use separate GPIO lines to signal the host. I3C introduces in-band interrupts (IBI), allowing any target device to request attention directly on the SDA line without additional pins.

Dynamic addressing: I2C devices have fixed or pin-configurable addresses, which can cause conflicts when multiple identical devices are on the same bus. I3C assigns addresses dynamically during bus initialization, eliminating address conflicts.

Pin compatibility: I3C uses the same two-wire SDA/SCL interface as I2C and supports legacy I2C devices on the same bus. This backward compatibility is a major factor in adoption — teams can migrate to I3C incrementally.

Power and pins: By eliminating dedicated interrupt lines and using dynamic addressing (removing address-select pins), I3C reduces total pin count per device, which matters in space-constrained designs like smartphones and wearables.

Why I3C Analysis Requires Specialized Tools

I3C’s higher data rates, dual-mode operation (SDR and HDR), and in-band interrupts make it significantly more complex to capture and decode than I2C. A basic logic analyzer that handles I2C well may miss critical I3C events because:

• The 12.5 MHz SDR clock requires a sample rate of at least 125 MS/s (10x oversampling) for reliable decode, and more for HDR modes.
• HDR-DDR mode transmits data on both rising and falling edges of SCL, doubling the effective data rate. The analyzer must decode DDR patterns correctly.
• In-band interrupts can occur during bus idle, and the analyzer must distinguish an IBI from a normal START condition.
• The bus initialization sequence (ENTDAA, SETDASA) uses a specific transaction flow that must be decoded to understand device address assignments.

Acute instruments — the BusFinder, LA4000, and PX2816B Protocol Exerciser — provide the sample rate, decode intelligence, and trigger capabilities needed for I3C analysis.

Capture Setup with BusFinder and LA4000

BusFinder Configuration

The Acute BusFinder protocol analyzer includes built-in protocol-specific front-end circuitry. For I3C:

1. Connect the BusFinder’s I3C bus interface to SDA and SCL on the target board. Connect ground.
2. In the Acute software, select Protocol > MIPI I3C Decode.
3. The BusFinder automatically handles voltage thresholds for push-pull (I3C) and open-drain (I2C legacy) signaling on the same bus.
4. Configure the expected SDR clock frequency. The decoder adapts to the actual clock rate, but setting an expected value helps the trigger engine.

LA4000 Configuration

For the LA4000 logic analyzer:

1. Connect two channels to SDA and SCL. Connect ground close to the bus to minimize ground loop effects.
2. Set the threshold voltage. I3C buses typically operate at 1.8V or 1.2V logic levels, so set the threshold to approximately 50% of VDD (0.9V for 1.8V systems, 0.6V for 1.2V systems).
3. Set the sample rate to at least 200 MS/s for SDR mode analysis, or 400 MS/s for HDR-DDR mode. The LA4000’s deep memory ensures you can capture at high sample rates for extended periods.
4. Open Protocol > MIPI I3C Decode and assign the SDA and SCL channels.

Sample Rate Guidelines

I3C Mode	Bus Speed	Minimum Sample Rate	Recommended Sample Rate
SDR	12.5 MHz	125 MS/s	250 MS/s
HDR-DDR	25 Mbps effective	250 MS/s	500 MS/s
HDR-TSP	25 Mbps effective	250 MS/s	500 MS/s
Legacy I2C (FM+)	1 MHz	10 MS/s	50 MS/s

Decoding SDR Mode Traffic

SDR (Single Data Rate) is the default operating mode for I3C. Data is clocked on the rising edge of SCL, similar to I2C but at much higher speeds. The Acute decoder displays SDR frames with:

• S / Sr / P: START, Repeated START, and STOP conditions
• Address + R/W: 7-bit dynamic address with read/write indicator
• ACK/NACK (T-bit): I3C uses a “T-bit” instead of I2C’s ACK. The T-bit also carries parity and end-of-data information
• CCC: Common Command Codes are displayed with their mnemonic names (ENTDAA, GETPID, RSTDAA, etc.)
• Data bytes: Payload data in hex, with optional ASCII overlay

Pay attention to the T-bit decode. In I2C, NACK simply means “not acknowledged.” In I3C, the T-bit is context-dependent — it may indicate end of data, parity error, or IBI request, depending on the transaction state.

HDR Mode Decode

I3C defines multiple High Data Rate modes for increased throughput:

HDR-DDR (Double Data Rate)

Data is transmitted on both rising and falling edges of SCL. The Acute decoder handles the DDR timing automatically, displaying each DDR word (16 bits of data plus a parity bit per word). HDR-DDR uses a specific ENTHDR CCC to enter the mode and a HDR EXIT pattern to return to SDR.

When analyzing HDR-DDR:

1. Verify the ENTHDR0 CCC is sent correctly before the controller switches to DDR signaling.
2. Check that the preamble and command word at the start of the HDR transaction are correct.
3. Monitor the CRC word at the end of each HDR transaction. CRC errors indicate signal integrity problems or timing violations.
4. Confirm the HDR EXIT pattern (four rising edges on SDA while SCL is low) returns the bus cleanly to SDR mode.

HDR-TSP and HDR-TSL

These ternary modes encode data using three signal levels. They are less commonly implemented but appear in high-bandwidth sensor applications. The Acute software decodes TSP/TSL frames when the target devices support them.

In-Band Interrupt Analysis

In-band interrupts are one of I3C’s most significant features and one of the most common sources of debugging issues. An IBI occurs when a target device drives SDA low during the bus idle state and wins arbitration for its address.

How IBIs Appear in Captures

In the Acute decode view, an IBI appears as:

1. A START condition initiated by the target (not the controller).
2. The target’s address with the R/W bit set to 1 (read).
3. An optional Mandatory Data Byte (MDB) that indicates the interrupt reason.
4. The controller ACKs or NACKs the IBI.

Common IBI Issues

IBI not acknowledged: The controller is not configured to accept IBIs from this target. Check the controller’s IBI enable registers and the target’s BCR (Bus Characteristics Register) to confirm IBI capability.

IBI timing violation: The target must drive SDA low within a specific window after detecting bus idle. If the target is too slow, the controller may initiate its own transaction first, and the IBI is lost. Measure the time between bus idle detection and IBI assertion using the analyzer’s cursor measurements.

IBI flooding: A malfunctioning target may continuously assert IBIs, starving other devices of bus time. The capture shows a repeating pattern of IBI-ACK-data with minimal gaps between requests.

I2C Backward Compatibility Testing

I3C buses often include legacy I2C devices alongside native I3C targets. Compatibility testing is essential because:

• I2C devices use open-drain signaling exclusively, while I3C uses push-pull for SDR and HDR modes. The controller must switch to open-drain when communicating with I2C devices.
• I2C devices do not understand I3C broadcast addresses or CCCs. They must correctly ignore these transactions without disrupting the bus.
• Clock speed for I2C devices must not exceed their rated speed (typically 400 kHz or 1 MHz), even though the I3C bus runs at 12.5 MHz for native devices.

To validate compatibility:

1. Capture a bus session that includes both I3C and I2C transactions.
2. Verify the Acute decoder correctly identifies which frames are I3C (push-pull, high speed) and which are I2C (open-drain, lower speed).
3. Check that I2C device transactions complete with proper ACKs at the correct clock speed.
4. Confirm that I2C devices do not respond to I3C broadcast CCCs. The capture should show no unexpected activity from I2C addresses during I3C-only transactions.

Common I3C Bus Issues

Dynamic Address Assignment Failures

During ENTDAA, each target sends its 48-bit Provisional ID, BCR, and DCR, then receives a dynamic address from the controller. If a device fails to respond during ENTDAA, it will not have a dynamic address and cannot participate in bus communication. Check the capture for the ENTDAA CCC and verify each expected device completes the assignment process.

Push-Pull Drive Strength Issues

I3C’s push-pull drivers can cause signal integrity problems on buses with significant capacitance or long traces. Unlike I2C’s open-drain signaling with controlled rise times, push-pull transitions are fast and can produce ringing. Use an MSO instrument to observe the analog waveform and check for overshoot exceeding 10% of VDD.

HDR Mode Entry/Exit Failures

If the controller sends ENTHDR but a target does not correctly enter HDR mode, the target may interpret HDR signaling as corrupted SDR data. The resulting errors appear as a burst of decode failures or unexpected NACK responses after the HDR sequence.

Summary

MIPI I3C protocol analysis demands instruments with high sample rates, multi-mode decode capability (SDR, HDR-DDR, HDR-TSP), and awareness of I3C-specific features like in-band interrupts and dynamic address assignment. Acute’s BusFinder, LA4000, and PX2816B Protocol Exerciser provide the capture fidelity, decode intelligence, and stimulus capability needed to debug I3C buses — including the critical mixed-bus scenarios where I3C and legacy I2C devices coexist.