Decoding I3C, Two Wires at a Time

A field guide to the Binho I3C Basic Protocol Analyzer for Saleae Logic

I3C squeezes dynamic addressing, in-band interrupts, hot-join and 12.5 MHz transfers onto the same two wires as I²C. That power is exactly what makes it painful to debug. Here’s how a logic-analyzer plugin turns raw bus edges back into readable transactions.

An I3C capture decoded: raw SCL/SDA edges resolved into a labeled transaction — Start, address, ACK, CCC, payload, Stop. (Illustrative, not bit-accurate.)

I²C was simple. I3C is capable — and stateful.

For three decades, I²C won design-ins because it asked for almost nothing: two wires, a couple of pull-ups, and a handful of static addresses. But every modern system eventually outgrew it — engineers added a dedicated interrupt GPIO for every sensor, fought address collisions between identical parts, and ran out of bandwidth long before the sensor data did.

The MIPI Alliance designed I3C to absorb all of those workarounds into the protocol itself, while staying backward-compatible enough that legacy I²C targets can still sit on the same bus. The openly published subset — I3C Basic — is what most embedded teams actually ship against today, with the analyzer supporting versions v1.0 through v1.2.

What I3C adds on top of two wires:

• Dynamic Address Assignment (DAA). The controller hands out 7-bit addresses at runtime, so two identical sensors no longer collide.

• In-Band Interrupts (IBI). A target can request attention over SDA itself — the per-device interrupt GPIO disappears.

• Hot-Join. A device can power up after the bus is already running and ask to be enumerated.

• Common Command Codes (CCC). A standardized command vocabulary, broadcast to everyone or directed at one target.

• Speed. Push-pull SDR up to 12.5 MHz, with HDR modes (including HDR-DDR) pushing throughput higher still — at lower power than I²C’s open-drain signaling.

WHY IT MATTERS

Every one of those features is stateful or bursty. A meter or a basic edge-counter sees voltage transitions; it doesn’t know that this particular burst was a hot-join request arbitrating against a device’s 48-bit Provisioned ID. That gap between “edges on a wire” and “what the bus is actually doing” is the entire job of a protocol analyzer.

One controller, multiple targets, two shared wires. Dynamic addresses are assigned at runtime; interrupts ride in-band on SDA; new devices hot-join — and legacy I²C parts still coexist.

The same two wires, three very different worlds.

Everything that moved into the protocol — addressing, interrupts, enumeration — is now invisible without a decoder that understands it.

	I²C	SPI	I3C Basic
Signal wires	2 (SCL/SDA)	4+ (CLK, MOSI, MISO, +CS each)	2 (SCL/SDA)
Max clock	up to 3.4 MHz (Hs-mode)	tens of MHz	12.5 MHz SDR · higher with HDR
Addressing	static 7/10-bit	one chip-select per device	dynamic (DAA), runtime-assigned
Interrupts	separate GPIO line	separate line	in-band (IBI), no extra pin
Add devices live	no	no	yes — hot-join
Multi-drop	yes	no	yes
Signalling / power	open-drain (higher)	push-pull	push-pull SDR (lower)
Legacy I²C parts	—	—	coexist on the same bus

WHAT ACTUALLY HAPPENS ON THE WIRE

Three sequences worth understanding before you debug them.

1 · Dynamic Address Assignment (ENTDAA)

Instead of trusting hardwired addresses, the controller broadcasts the ENTDAA command and lets targets arbitrate. Each device shifts out its 48-bit Provisioned ID plus its BCR and DCR characteristic registers; the lowest ID wins each round and is handed a fresh dynamic address. The process repeats until every device is enumerated.

ENTDAA: arbitration by Provisioned ID, then a fresh dynamic address per device — repeated until the bus is fully enumerated.

2 · In-Band Interrupts (IBI)

An I²C target that needs attention toggles a dedicated GPIO. An I3C target simply issues a Start and drives its own address onto SDA. If it wins arbitration, the controller recognizes the interrupt, reads any mandatory data byte, and services it — no interrupt pin required. It’s elegant, and it’s exactly the kind of asynchronous event that’s miserable to catch without a triggerable decoder.

An in-band interrupt: the target raises attention over SDA, wins arbitration, delivers its payload, and is serviced — all on the two-wire bus.

3 · Common Command Codes (CCC)

CCCs are I3C’s standardized command vocabulary. A broadcast CCC is addressed to reserved address 0x7E and reaches every target at once (think ENTDAA, RSTDAA, ENEC/DISEC). A direct CCC targets a single device by its dynamic address to get or set per-device parameters (GETPID, GETBCR/GETDCR, SETMWL/SETMRL). Decoding these by name — rather than as anonymous byte runs — is the difference between reading a log and reverse-engineering one.

Broadcast CCCs go to reserved address 0x7E and hit every device; direct CCCs target a single dynamic address. A good decoder labels each by name and field.

FROM EDGES TO TRANSACTIONS

The Binho I3C Basic Protocol Analyzer for Saleae Logic.

Traditionally, watching I3C at this level meant wheeling out silicon-validation equipment — expensive, lab-bound, and overkill for day-to-day firmware work. This plugin moves that capability into the tool most embedded engineers already have open: Saleae Logic. It decodes the bus on two levels at once.

The same capture, three ways: raw edges, individual bytes/ACKs, and high-level transactions you can actually reason about — including CCCs, private reads/writes, IBIs and hot-joins.

What the plugin decodes

• Full spec + speed coverage. I3C Basic v1.0 → v1.2, 12.5 MHz SDR and HDR-DDR modes.

• Direct & broadcast CCC decode. Commands resolved by name and field, not raw bytes.

• IBI & hot-join capture. Catch in-band interrupts and hot-join requests as first-class events.

• Private read & write. SDR private transfers decoded against each device’s dynamic address.

• Real-time decode + HLA. Live decoding with High-Level Analyzer extensions for custom views.

• Automation-ready. A Python automation API drives I3C analysis inside your test frameworks.

Reference docs: Plugin datasheet  ·  User’s guide

WHERE IT FITS

From first power-on to production validation.

The same plugin follows a design through its whole life — only the question being asked changes.

PHASE 01 Firmware bring-up Confirm the controller enumerates the bus and speaks valid CCCs.

PHASE 02 Driver development Trace private reads/writes and IBIs while the driver takes shape.

PHASE 03 Automated test Script captures and assertions into CI via the Python API.

PHASE 04 Validation Prove timing, utilization and edge-case behavior before sign-off.

Representative applications

• DDR5 / JESD300-5 SPD. Inspect Serial Presence Detect traffic on DDR5 memory modules, where I3C Basic now lives.

• MCTP over I3C / BMC. Debug management-plane transport between a BMC and managed devices.

• Sensor subsystems. Bring up IMUs and MEMS sensors that moved from I²C to I3C for IBI and speed.

• Driver validation. Verify a driver against real silicon, not just spec-compliant captures.

• Performance analysis. Measure bus utilization and timing, then optimize transfer scheduling.

• Interop debugging. Hunt the edge cases that surface when multi-vendor parts share one bus.

COMPATIBILITY

Works with the Saleae stack you already run.

Software

• Saleae Logic 1.x — version 1.2.29 and up.

• Saleae Logic 2.x — version 2.3.43 and up.

• Cross-platform — Windows, macOS & Ubuntu.

Hardware

• Saleae Logic MSO — full compatibility, including analog analysis.

• Logic Pro 8 / Pro 16 — full compatibility.

• Saleae Logic 8 — supported; I3C bus voltage must stay ≥ 1.8 V.

The Saleae Logic pro16

REQUIRES

This is a plugin: it needs Saleae hardware plus Saleae’s Logic desktop software, which Saleae provides free of charge for use with their devices. The plugin adds the I3C decode layer on top.

LICENSING

Two tiers. Pay for the access pattern you need.

Both options work with any Saleae Logic device — the difference is how the seat is bound.

Flex Licensing

Share one license across team members on internet-connected machines — no license server to stand up.

• Shared among team members

• Internet connection required

• No license-server setup

• Works with any Saleae Logic device

Node-Locked Licensing

Bind the license to one machine for air-gapped or secure environments — still no server setup.

• Locked to a specific computer

• No internet required

• Runs in secure / isolated environments

• Works with any Saleae Logic device

IN THE DOWNLOAD

What a purchase includes.

• Analyzer plugin binaries — Windows (.dll), macOS (.so), Linux (.so).

• I3C Transactions HLA extensions

• Automation API example scripts (Python).

• Example I3C capture files (.sal).

• Getting Started guide (PDF).

• Analyzer datasheet (PDF).

WHY THIS DECODER, SPECIFICALLY

Built by people in the room where the spec is written.

A decoder is only as trustworthy as its authors’ understanding of the protocol’s gray areas. Per Binho, the analyzer’s pedigree is unusually deep here — the same team helps shape I3C and proves the tool against real silicon, not just spec-compliant captures.

2023 Active in the MIPI I3C Working Group since — with a founder serving as co-vice chair.

4× Brought to the MIPI I3C Plugfest four years running — Munich ’22, San Jose ’23, Taipei ’24, Warsaw ’25.

200+ Semiconductor companies use Binho tools to develop and ship I3C-capable devices.