Electronics Guide

Origins, Versions, and Licensing

The MIPI Alliance developed I3C to unify the sensor interfaces in mobile devices, where a single handset might carry a dozen sensors split awkwardly across I2C buses, SPI buses, and a thicket of dedicated interrupt lines. The working group's goal was a single bus that could carry all of that traffic on two pins without giving up the low power and low pin count that made I2C attractive in the first place. SPI could supply the bandwidth, but it costs a chip-select line per peripheral and defines no standard way to enumerate devices or to let one raise an interrupt, so both the pin count and the software burden grow with every sensor added.

Specification Revisions

Version 1.0 was adopted at the end of 2016 and published for public download in December 2017. It established the core protocol: a 12.5 MHz single-data-rate mode, dynamic address assignment, common command codes, in-band interrupts, hot-join, secondary controllers, and the first high-data-rate modes. Version 1.1, published in December 2019, added the bulk transport high-data-rate mode, multi-lane operation, grouped addressing, device-to-device tunneling, and a standardized target reset. Version 1.1.1 followed in June 2021 and carried the terminology change that also propagated into the I2C specification, replacing master and slave with controller and target. Version 1.2, released in February 2025, reorganized the document into a modular form that separates mandatory behavior from optional behavior, so that an implementer can see at a glance which features a conformant device must provide.

I3C and I3C Basic

MIPI publishes the full I3C specification to its members. Alongside it, the alliance publishes I3C Basic, first issued in 2018, a subset that any implementer may obtain publicly and use royalty-free. I3C Basic exists precisely so that other standards bodies and non-member vendors can adopt the bus without joining MIPI, and its practical importance is hard to overstate: most silicon outside the mobile ecosystem targets I3C Basic rather than the full specification.

I3C Basic is not a crippled version. It carries dynamic address assignment, common command codes, error detection and recovery, secondary controllers, target reset, in-band interrupts with a mandatory data byte, and the hot-join mechanism. Since version 1.1.1 it also includes the double-data-rate and multi-lane bulk-transport high-data-rate modes, grouped addressing, and one mode of asynchronous timing control. What the full specification reserves to members is the narrower set: the ternary-symbol high-data-rate modes, synchronous timing control and the higher asynchronous timing modes, device-to-device tunneling, multi-lane operation applied to the single-data-rate and double-data-rate modes, and monitoring-device early termination. I3C Basic v1.2 carries the same reorganization as the full v1.2 specification: MIPI dates the document to April 2025 and opened it for public download in August of that year.

Adoption by Other Standards

JEDEC built the DDR5 module sideband bus on I3C Basic, publishing it as JESD403-1 in October 2020. That bus carries management traffic among the serial presence detect hub, the on-module power management integrated circuit, the registering clock driver, and the temperature sensors, replacing the I2C link that served the same role on DDR4 modules. JEDEC's version is both a subset and a superset of I3C Basic: it constrains some options and adds a hub function that raises the device count without giving up the full 12.5 MHz clock, while retaining a slower I2C-compatible mode to ease the industry transition. MIPI has likewise extended its own Camera Control Interface, historically an I2C subset, to run over I3C.

Electrical Layer and Signaling

I3C uses the same two conductors as I2C. SCL carries the clock and SDA carries data, and both are shared by every device on the bus. What changes is how those lines are driven.

Push-Pull and Open-Drain Phases

I2C drives both lines open-drain: a device pulls the line low and releases it, and a pull-up resistor restores the high level. That arrangement permits arbitration and clock stretching, but it also caps the speed, because the rise time is set by an RC network formed from the pull-up resistance and the bus capacitance.

I3C keeps open-drain drive only where the protocol genuinely needs it, and switches to push-pull everywhere else. The controller drives SCL push-pull at all times, which is why I3C does not support clock stretching. SDA alternates: the address header, the acknowledgment, arbitration during address assignment, and in-band interrupt requests all use open-drain, because those phases depend on several devices being able to pull the line low simultaneously without contention. Once the transaction reaches its data payload, the transmitting device drives SDA push-pull. Removing the pull-up from the critical path is what allows the 12.5 MHz clock. During the brief turnarounds when no device drives SDA, the controller applies a weak bus keeper that holds the line at its last level rather than letting it float.

Push-pull drive also lowers the energy cost of a transfer. An open-drain line dissipates static current through its pull-up for as long as a device holds the line low, so an I2C byte costs power in proportion to how long it takes and how many of its bits are zeros. A push-pull driver only charges and discharges the line capacitance, which makes the energy per bit a function of the capacitance and the supply voltage rather than of the resistor. That is why I3C can be both faster than I2C and cheaper to run at a given rate.

Voltage, Capacitance, and Device Count

The specification defines nominal signaling levels of 1.2, 1.8, and 3.3 volts, and it derives most of its timing parameters from a 4 milliampere driver working into a 50 picofarad bus load. That 50 picofarad figure is far tighter than I2C's 400 picofarad allowance, and it is the practical limit on how large an I3C bus can grow. Trace length, connector stubs, and every device's pin capacitance consume the budget together, and they consume it quickly: MIPI's own worked example puts FR4 board trace at roughly 2.2 picofarads per inch, so twenty inches of routing accounts for some 44 picofarads before a single device is attached. An I3C bus is therefore a short, board-level bus rather than a cable-length one.

Version 1.0 stated a hard ceiling of eleven target devices on a bus. Version 1.1.1 withdrew that fixed number, on the reasoning that loading rather than addressing is the real constraint; the 7-bit dynamic address space has room to spare, and a bus of light, closely spaced devices may exceed eleven where a bus of heavy ones cannot reach it. When a design needs more devices or more reach than the capacitance budget allows, the remedies are to lower the clock or to insert a hub, which is exactly the approach JEDEC took for DDR5 modules.

A pull-up resistor is still required on SDA, sized for the open-drain phases in the same way as on an I2C bus. Because those phases are short and infrequent relative to the push-pull payload, the resistor no longer dictates the achievable data rate. It does, however, still dictate whether address arbitration and acknowledgment work reliably, so it cannot be omitted or made arbitrarily large.

Device Roles and Bus Configurations

I3C defines a small set of roles, and a physical device may occupy different roles at different times.

Roles

The active controller is the device that currently owns the bus: it drives the clock, initiates transactions, and assigns addresses. Exactly one active controller exists at any moment. A secondary controller is capable of controlling the bus but is presently behaving as a target. It asks for the bus with a controller-role request, and the active controller grants that request by issuing the GETACCCR command, named GETACCMST before the version 1.1.1 terminology change. The active controller keeps its secondaries current beforehand with DEFTGTS, the command that publishes the present list of targets and group addresses, so the incoming owner inherits a populated device table instead of having to re-enumerate the bus. This is a cleaner arrangement than I2C multi-master arbitration, because ownership transfers by negotiation rather than by collision. A target is an ordinary I3C peripheral that responds to its assigned dynamic address. A legacy I2C target is an unmodified I2C device sharing the same two wires.

Bus Configurations

The mix of devices present determines how fast the bus may run. A pure bus contains only I3C devices and operates at full speed with no compatibility constraints. A mixed fast bus adds legacy I2C targets that carry the mandatory 50 nanosecond spike filter on both their SCL and SDA inputs; because a 12.5 MHz I3C clock holds SCL high for only about 40 nanoseconds, the filter suppresses those pulses entirely and the legacy devices never perceive the fast traffic, so the bus still runs at full speed. A mixed slow bus and a mixed limited bus cover the cases where legacy devices lack the spike filter; there the whole bus must slow to a rate the legacy parts tolerate. The lesson for designers is direct: a single unfiltered legacy device on the bus costs every other device its speed advantage.

Dynamic Address Assignment

I2C's most persistent irritation is the fixed address. A designer who needs four identical temperature sensors on one bus discovers that the part offers only two address-select pins, and must then add a multiplexer, a second bus, or a different sensor. I3C removes the problem by assigning addresses at runtime.

The ENTDAA Procedure

The controller begins by broadcasting the ENTDAA command, which instructs every target that does not yet hold a dynamic address to participate. Each such target then drives, in open-drain mode and most-significant bit first, a 64-bit identifier consisting of its 48-bit provisioned ID, its bus characteristics register, and its device characteristics register. Because the drive is open-drain, the sequence arbitrates naturally: a device that intends to transmit a one but observes the line pulled low has lost, and it withdraws quietly to try again on the next round. The device with the numerically lowest identifier survives, the controller reads its full identifier, and the controller then writes back a 7-bit dynamic address of its choosing. The procedure repeats until no device answers, at which point the controller has an enumerated inventory of the bus.

The provisioned ID is a 48-bit value combining a MIPI-assigned manufacturer identifier with vendor-defined part and instance fields; the instance field is what distinguishes otherwise identical parts, and it is typically set by pin strapping or non-volatile memory. The bus characteristics register reports protocol capabilities: the device's role, whether it can request in-band interrupts, whether such a request carries a mandatory data byte, whether the device can go offline, and whether its maximum data rate is limited. The device characteristics register holds an 8-bit device type code drawn from a registry MIPI maintains, so a controller can learn that a newly enumerated device is an accelerometer or a gyroscope without any prior configuration.

Alternatives and Address Management

Full arbitration is not always necessary. SETDASA assigns a dynamic address directly to a device already known by a static I2C address, which is faster than arbitration when the bus composition is fixed and known. SETAASA, added in version 1.1 and present in I3C Basic from its first release, tells every capable device to adopt its own static address as its dynamic address, collapsing enumeration into a single broadcast. SETNEWDA reassigns a device's address later, and RSTDAA discards all assignments so that enumeration can start over.

A handful of addresses are reserved and never assigned. The broadcast address 0x7E prefixes every transaction, and 0x02 signals a hot-join request. Beyond the reserved list, the controller must also refuse every address that differs from 0x7E in a single bit, so that one corrupted bit cannot turn an ordinary target address into the broadcast address or the reverse. A good controller leaves gaps in the assigned range as well, both to keep room for hot-join arrivals and to allow later adjustment of interrupt priority, which depends on address order.

Common Command Codes

I3C standardizes bus management in a set of common command codes, a layer I2C never had. Every I2C device defines its own register map and its own conventions for resetting, querying, or configuring itself; I3C instead defines a shared vocabulary that any controller can use against any compliant target.

A broadcast command follows the 0x7E header with a code in the lower half of the code space, and every target on the bus acts on it. A direct command uses a code in the upper half, followed by a repeated start and a specific target address, so that the command applies to one device and may return data from it. The command set covers event control through ENEC and DISEC, which enable and disable in-band interrupts, controller-role requests, and hot-join independently; address management through ENTDAA, SETDASA, SETAASA, SETNEWDA, and RSTDAA; capability discovery through the commands that read back the provisioned ID, the two characteristics registers, the maximum sustainable data speed, and the device's status; flow control through the commands that set and read maximum write and read lengths; entry into the high-data-rate modes; the standardized target reset action; and, from version 1.1, grouped addressing, which lets a controller write the same payload to several targets at once under a shared group address.

The practical payoff is generic driver code. An operating system can enumerate an I3C bus, discover what is attached, negotiate transfer sizes, and reset a misbehaving device without a device-specific driver for any of those steps.

In-Band Interrupts

An I2C target cannot speak until spoken to. A sensor that needs to report a completed conversion either waits to be polled, which wastes power and adds latency, or asserts a dedicated interrupt line, which costs a pin on both ends and a trace between them. A design with eight interrupt-driven sensors needs eight such lines.

How a Target Requests Attention

I3C lets a target raise an interrupt on the data line itself. When the bus is idle, having been free for at least the specified bus-available period of roughly one microsecond, a target that needs service pulls SDA low. The active controller detects the transition, pulls SCL low to form a start condition, and begins clocking. The target then transmits its own dynamic address in open-drain mode. If several targets request service simultaneously, the same open-drain arbitration that governs address assignment resolves the contest, and the device with the numerically lower address wins. This gives the system designer a direct latency control: assigning low dynamic addresses to the targets whose interrupts matter most makes them win arbitration, and the controller chooses those addresses during enumeration.

The controller acknowledges the request, at which point the target may send a mandatory data byte that identifies the reason for the interrupt, and depending on the device's configuration, additional payload bytes after it. A sensor can therefore report an event and deliver its sample in the same transaction, without the controller performing a separate read. The controller may instead not-acknowledge the request when it is busy, and it can disable a target's interrupts altogether with DISEC.

Hot-Join

Hot-join lets a device announce itself on a bus that is already operating, whether because it was physically connected after startup, because it was held in reset, or because its power rail was switched on late to save energy. Without it, a controller would have to poll for new devices or re-enumerate the whole bus periodically.

A joining device always enters the bus as a target; only after initialization may it become a secondary controller. Before announcing itself, it must observe a bus idle condition, meaning both lines have remained high continuously for at least the specified idle period, approximately 200 microseconds in version 1.1 and later. Version 1.0 specified one millisecond, so a bus that mixes device generations may see the longer interval. The device therefore needs an internal oscillator good enough to time that interval, and it must ignore any address-assignment command issued before it has made its request.

The request itself is a special in-band interrupt. The device pulls SDA low, the controller responds by pulling SCL low to create a start and then clocking the line, and the device transmits the reserved address 0x02 with the read/write bit set to write. The controller has three reasonable responses: not-acknowledge the request outright; acknowledge it but suppress further requests by broadcasting DISEC with the hot-join disable bit set; or acknowledge it and issue ENTDAA to bring the new device into the address inventory.

Hot-join behavior deserves explicit thought at design time. A device powered up at the same time as the bus should not attempt to hot-join, because the controller is about to enumerate it anyway, and a request arriving during initialization can be missed entirely if the controller is holding SCL low. For that reason, well-designed parts make hot-join behavior configurable through pin strapping or non-volatile memory rather than hard-wiring it.

Data Transfer Modes

I3C defines one mandatory transfer mode and a family of optional faster ones. All of them run over the same two wires and are entered and exited under protocol control, so a bus can mix them transaction by transaction.

Single Data Rate

Single data rate, or SDR, is the baseline and the mode every I3C device supports. It clocks SCL at up to 12.5 MHz and moves one bit per clock, giving a raw rate of 12.5 megabits per second. Each 8-bit data word is followed by a ninth bit, so the payload throughput is eight-ninths of the raw figure, 11.1 megabits per second, which is the number MIPI quotes as I3C's typical data rate. That ninth bit does different work in each direction: on a write it carries odd parity over the byte just sent, and on a read it serves as a handshake by which the target signals more data to follow or the controller aborts the transfer early.

Every SDR frame opens with a start condition followed by the broadcast address 0x7E. That prefix is what keeps legacy I2C devices quiet, since none of them respond to it, and it also gives combined I3C and I2C targets a defined point at which to engage their spike filters. After the header the controller either issues a broadcast command or performs a repeated start and addresses a specific device.

High Data Rate Modes

The controller enters a high-data-rate mode by issuing the corresponding ENTHDR broadcast command, and the bus returns to SDR through a defined exit pattern. Where SDR relies on parity, the HDR modes protect their payloads with a cyclic redundancy check.

HDR-DDR transfers data on both clock edges, doubling the raw rate to 25 megabits per second at the same 12.5 MHz clock. Command, parity, and check-word overhead reduce the useful figure to roughly 20 megabits per second. HDR-DDR is the most widely implemented optional mode and is included in I3C Basic.

HDR-TSP and HDR-TSL encode data as ternary symbols across the two wires rather than as binary levels on one, raising the raw rate to 33.3 megabits per second at the same clock. That is the highest figure the bus reaches on a single lane, and it yields roughly 30 megabits per second of payload in the TSP variant. TSL delivers less, because it inserts stuffing symbols so that legacy I2C devices on a mixed bus continue to ignore the traffic. Both modes remain exclusive to the full specification.

HDR-BT, the bulk transport mode introduced in version 1.1, is designed for large block transfers and can spread data across as many as four lanes, reaching raw rates approaching 100 megabits per second. It is included in I3C Basic, which makes it the practical route to high throughput for implementers outside MIPI. The full specification additionally allows multi-lane operation to be applied to the SDR and HDR-DDR modes.

Timing Control

Sensor fusion depends on knowing when each sample was taken, not merely the order in which samples arrived. I3C addresses this with timing control, which lets a controller establish a shared time reference and lets targets report the precise sampling instant of the data they return. Synchronous timing control distributes a periodic reference derived from the bus clock; asynchronous timing control instead attaches timing information to individual transfers. The distinction matters for licensing as well as for design, because I3C Basic includes only the first asynchronous mode, while synchronous control and the higher asynchronous modes remain in the full specification.

I2C Backward Compatibility

Backward compatibility is the feature that makes I3C adoptable, and it works by a combination of protocol and electrical measures rather than by any single trick.

At the protocol level, the 0x7E broadcast header at the start of every I3C frame is an address no legacy device answers, so legacy targets stay silent through all I3C-specific activity. At the electrical level, the specification requires any I2C device sharing an I3C bus to carry a 50 nanosecond spike filter on both its SCL and SDA pads. Because I3C holds its high-speed SCL pulses well inside that window, a filtered legacy device simply does not see high-speed traffic and cannot be confused by it. Where it is not known whether a given part has the filter, MIPI defines a probe for it: address the device with a clock pulse shorter than 50 nanoseconds, and an unfiltered device acknowledges while a filtered one stays silent.

Several I2C behaviors do not survive the transition. Clock stretching is not available, because the controller drives SCL push-pull; a legacy device that stretches the clock will fight that driver and cannot share the bus. Ten-bit addressing is likewise unsupported, and only Fast mode and Fast-mode Plus legacy parts are accommodated at all; slower or otherwise nonstandard I2C devices have no place on the bus. A legacy device's static address must not collide with any I3C reserved address or with a dynamic address the controller intends to assign, which means the controller must know the static addresses in advance and exclude them from its assignment pool. And, as noted above, a legacy device without a spike filter forces the entire bus down to a speed it can tolerate.

The practical consequence is that most designs treat compatibility as a migration aid rather than a permanent architecture. A board carries its legacy parts through one or two product generations while newer I3C-native devices arrive, and the bus reverts to pure-bus operation once the last legacy part is designed out.

Error Detection and Recovery

Error handling is mandatory in I3C, which is a notable departure from I2C practice, where recovery from a hung bus is left to each implementer's ingenuity. SDR transfers carry parity on write data and use the ninth bit as an early-termination handshake on reads; HDR transfers carry a cyclic redundancy check. The specification enumerates error conditions for both controllers and targets, assigns each a code, and prescribes a recovery action for each, so a compliant device recovers deterministically rather than by heuristic.

The standardized target reset introduced in version 1.1 completes the picture. A controller can command a specific target, or every target, to perform a defined reset action ranging from resetting only the I3C peripheral to resetting the whole device, using a documented signaling pattern. This replaces the I2C ritual of bit-banging clock pulses until a stuck target releases SDA, and it means an embedded system can restore a wedged sensor without cycling power to the board.

Implementation in Hardware and Software

I3C is more complex than I2C at every level, and that complexity has to live somewhere.

Silicon and Controller Blocks

Bit-banging is not a realistic option: the mode switching between open-drain and push-pull, the arbitration during address assignment, the detection of an in-band interrupt during an idle bus, and the timing tolerances at 12.5 MHz all require hardware. Microcontroller vendors have added dedicated I3C controller blocks accordingly, and many parts expose a combined block that can operate as an I2C controller, an I3C controller, or an I3C target depending on configuration. On the target side, sensor vendors increasingly ship parts with dual-mode interfaces that come up as I2C devices and switch to I3C once the controller assigns a dynamic address. Direct memory access matters here as it does on any fast peripheral, because interrupt-per-byte servicing squanders the bandwidth advantage the bus was adopted for.

Driver Frameworks

Software support has matured alongside the silicon. The Linux kernel gained a dedicated I3C subsystem in version 5.0, released in 2019, providing a controller-driver interface, a device model that handles dynamic addressing and in-band interrupts, and a path for legacy I2C devices on a mixed bus. The Zephyr project added an I3C device-driver API in version 3.2, released in 2022, together with its first controller drivers and I3C-capable sensor drivers. Both frameworks reflect a structural difference from I2C: because I3C enumerates its own bus and reports device types, drivers bind to discovered devices rather than to addresses hard-coded in a device tree, much as they do on USB or PCI Express.

Instrumentation and Bring-Up

Debugging an I3C bus requires instruments that decode it. A logic analyzer configured for I2C will misread the traffic completely, since it cannot follow the mode switches, the broadcast header, or the high-data-rate encodings. Protocol analyzers with I3C decoding, and oscilloscopes with the corresponding trigger and decode options, are effectively prerequisites for bring-up. It is also worth capturing the enumeration sequence early, because most bring-up problems surface there: a device absent from the inventory usually means its identifier arbitration failed or its open-drain drive was too weak, and a device that enumerates but never interrupts usually means the controller never sent the ENEC command that enables its events.

Design and Troubleshooting Considerations

Several issues recur often enough on I3C designs to be worth anticipating.

Capacitance budget. The 50 picofarad target is easy to exceed. Long traces, connectors, and a generous device count each consume part of it, and exceeding it degrades edges until the bus fails intermittently at full speed while working at reduced clock. Budget the capacitance during layout rather than diagnosing it afterward.

Duplicate provisioned identifiers. Two identical parts that ship with the same instance field will present the same 64-bit identifier during arbitration, and neither will ever lose. Parts intended for multi-instance use provide a strapping pin or a programmable field for exactly this reason, and it must be set differently on each instance.

Static-address collisions. On a mixed bus, a legacy device whose static address coincides with a dynamic address the controller assigns produces a device that answers transactions meant for another. The controller's assignment pool must exclude every static address on the board.

Unexpected hot-join traffic. Devices that hot-join at power-up, when the controller is about to enumerate them anyway, generate requests during initialization that the controller may miss or must repeatedly refuse. Configure such devices not to hot-join when they share the bus's power domain.

Interrupt latency and address choice. Because in-band interrupt arbitration favors lower addresses, dynamic address assignment is a real-time design decision, not a bookkeeping detail. Assign the low addresses deliberately to the targets with the tightest deadlines.

Mixed-bus speed collapse. One legacy target lacking a spike filter reduces the whole bus to its tolerance. When that device is essential, consider placing it on a separate I2C bus rather than sacrificing the speed of everything else.

Applications

Mobile sensor hubs were the first significant deployment and remain the canonical case: accelerometers, gyroscopes, magnetometers, pressure sensors, and ambient light sensors share two pins, report events through in-band interrupts, and timestamp their samples through timing control, which is what makes credible sensor fusion possible without a wire per device.

Memory modules are the highest-volume deployment. Every DDR5 module carries a sideband bus built on I3C Basic, over which the host configures the on-module power management integrated circuit, reads the serial presence detect data, and polls temperature sensors.

Automotive and industrial sensing adopt I3C for the same reasons as mobile, with the added attraction of hot-join for modules that power up independently and of standardized target reset for fault recovery in systems that cannot be power-cycled casually. General-purpose microcontrollers now commonly expose I3C alongside I2C and SPI, which brings the bus to designs that simply want more sensor bandwidth on the same two pins. Camera modules are a further case, since MIPI extended its Camera Control Interface to run over I3C rather than only over the I2C subset it originally specified.

Summary

I3C preserves I2C's two-wire economy while removing the constraints that limited it. Push-pull signaling on the data payload lifts the raw base rate to 12.5 megabits per second, of which 11.1 is payload, and the optional modes reach 25 megabits per second on one lane in double-data-rate form, 33.3 in ternary form, and up to 100 megabits per second across four lanes in bulk transport. Dynamic address assignment ends address collisions and gives the controller a self-describing inventory of the bus. In-band interrupts eliminate dedicated interrupt lines and make interrupt priority a configurable property of address assignment. Hot-join supports devices that appear after startup, and standardized common command codes, error recovery, and target reset replace per-device conventions with a shared protocol layer.

Backward compatibility with legacy I2C targets makes migration incremental rather than disruptive, provided the designer respects its conditions: no clock stretching, no address collisions, and a spike filter on every legacy part that must not slow the bus. The royalty-free I3C Basic subset carries nearly everything a typical embedded design needs, which is why adoption has moved well beyond the mobile handsets the bus was conceived for and into memory modules, vehicles, and general-purpose microcontrollers.

Related Topics