I3C: MIPI's I²C successor for high-rate embedded sensors

A single IMU sampled at several kHz takes more than 70 percent of an I²C Fast-mode Plus bus; on an I3C bus in SDR mode, the same sensor takes less than 6 percent. The I3C bus (Improved Inter-Integrated Circuit), standardised by the MIPI Alliance through the I3C Basic v1.1.1 specification, succeeds I²C by delivering 12.5 Mbit/s in SDR mode and up to 25 Mbit/s in HDR-DDR, without breaking compatibility with existing I²C parts. For designers saturating an I²C Fast-mode Plus bus at 1 MHz with multi-axis MEMS sensors or environmental sensor hubs, I3C is now the natural evolution path.

At AESTECHNO, with a team that has spent over 10 years designing embedded boards around STM32 and Nordic nRF microcontrollers, we have followed this protocol since the first I3C-capable MEMS shipped (STMicroelectronics LSM6DSO32X, Bosch BMI323). The new bus lifts the I²C throughput ceiling while cutting I/O power thanks to its 1.2 V / 1.8 V signalling. This guide covers the electrical architecture, transmission modes, dynamic addressing, in-band interrupts, and the design pitfalls to anticipate.

I3C: definition and positioning vs I²C

The I3C bus is a two-wire serial protocol standardised by the MIPI Alliance starting in 2016, designed as the logical successor to I²C with backward compatibility and data rates ten to twenty times higher. The public I3C Basic v1.1.1 specification covers the SDR and HDR-DDR modes and the full set of Common Command Codes required for a commercial design, with no paid licence for system integrators.

This protocol answers three needs that have become critical: the densification of MEMS sensors around microcontrollers, the elimination of dedicated INT lines that burn precious GPIOs, and the reduction of I/O power through low-voltage signalling. The protocol is codified by the MIPI I3C Basic v1.1.1 specification and positioned by the MIPI Alliance as the de-facto replacement for I²C in products designed after 2024.

The key differences versus I²C come down to three points: a push-pull physical layer at 12.5 MHz (versus open-drain capped at 1 MHz in Fast-mode Plus), a dynamic addressing scheme that replaces static 7-bit addresses, and a standardised command set (CCC) that unifies multi-vendor device configuration. These three changes alone justify the migration on any new high-rate sensor design.

To anchor the comparison for engineers weighing a migration, the side-by-side table below summarises how the two buses behave on the dimensions that drive a sensor-hub architecture. According to the MIPI Alliance v1.1.1 specification and the NXP UM10204 I²C reference manual, the transition is most useful exactly where the I²C line items sit at their physical limit.

Electrical architecture: push-pull, 12.5 MHz, backward compatibility

The electrical architecture of the protocol is built on active push-pull drivers that drive SCL continuously and SDA during master write phases. This choice breaks with I²C's open-drain logic and allows a 12.5 MHz clock in SDR mode with a single pull-up on SDA, while cutting dynamic power on a typical sensor bus.

Concretely, the I3C master drives SCL push-pull at all times and toggles SDA between push-pull during data transmit and open-drain when a slave responds. This dynamic management of the physical layer allows coexistence with legacy I²C components while reaching 12.5 MHz on pure I3C exchanges. The recommended signalling is 1.8 V, with optional 1.2 V support for low-power architectures and 3.3 V for backward compatibility with an existing I²C ecosystem.

In practice, sizing the single pull-up on SDA is more forgiving than in I²C: a value of 1.8 kΩ to 2.2 kΩ covers most mixed buses up to 20 cm of trace, versus the paired 4.7 kΩ / 4.7 kΩ that had to be recomputed against total capacitance in Fast-mode Plus. For EMC compliance, we follow the IPC-2221 controlled-impedance rules and the IEC 61000-4-x families for ESD and burst tests on industrial products.

Transmission modes: SDR, HDR-DDR, HDR-TSL/TSP

The protocol is structured around four transmission modes codified in the full MIPI I3C specification (I3C Basic v1.1.1 keeps only SDR plus the HDR-DDR and HDR-BT modes). SDR mode (Single Data Rate) reaches 12.5 Mbit/s and covers the vast majority of sensor use cases. The HDR (High Data Rate) modes double that rate or more for audio streaming, imaging, or multi-axis inertial data sampled at several kHz.

The HDR-DDR mode is the simplest to implement on the slave side because it reuses the SDR wiring by sampling on both clock edges. The HDR-TSL (Ternary Symbol Legacy) and HDR-TSP (Ternary Symbol Pure) modes encode several bits per transition to exceed 30 Mbit/s, at the cost of additional hardware complexity that limits adoption to multimedia SoCs.

In practice, SDR mode amply covers industrial needs: a 10 MHz SDR bus comfortably carries eight IMUs at 1 kHz (accelerometer, gyroscope, magnetometer on three axes each), whereas an equivalent I²C Fast-mode Plus bus saturates at three IMUs with a tight timing budget. Switching to HDR-DDR stays reserved for very high-rate sensor-fusion architectures (6.4 kHz and above across 32 channels). For factory-floor architectures that already speak Modbus over RS-485 to a PLC, I3C complements rather than replaces that link: I3C handles the local sensor cluster on the board, and the RS-485 segment carries the aggregated Modbus payload to the wider machine. CAN-FD and CANopen serve a different niche again, with longer reach and deterministic latency that I3C does not target. The same applies to ISO 11898 classical CAN, J1939 truck buses, and FDCAN controllers backed by an NXP TJA1042 transceiver SIC: they cover off-board, vehicle-grade communication, where I3C stays an on-board, sensor-hub protocol. JTAG (IEEE 1149.1) sits at yet another layer entirely, used for boundary-scan and debug rather than runtime data exchange.

Dynamic addressing and Common Command Codes (CCC)

Dynamic addressing is the replacement of factory-fixed I²C addresses with an orchestrated assignment at boot by the master, through the ENTDAA procedure (Enter Dynamic Address Assignment). Each device receives a unique 7-bit address negotiated against its 48-bit PID (Provisioned ID), eliminating the recurring conflicts between sensors sharing the same static address.

In the STMicroelectronics MEMS catalogue, the LIS2DW12 and LSM6DSO accelerometers historically share the 0x18/0x19 and 0x6A/0x6B addresses. Beyond two identical sensors on the same bus, an I²C design needs a TCA9548A multiplexer or a PCB respin to work around these collisions. The new protocol resolves the issue definitively: no matter how many identical parts coexist, each one gets its dynamic address at bus initialisation.

Common Command Codes (CCC) standardise cross-vendor configuration. Among the most-used CCCs in practice:

• ENTDAA: triggers dynamic address assignment on the bus.
• RSTDAA: resets all dynamic addresses (useful before reconfiguration).
• SETDASA: assigns a dynamic address from an existing static I²C address (migration path).
• ENEC / DISEC: enables or disables asynchronous events (IBI, hot-join) per slave.
• GETCAPS: reports the declared capabilities of a device (HDR, IBI, maximum rate).
• SETMWL / SETMRL: negotiates write and read buffer sizes.

In practice, disciplined CCC use avoids days of debugging: an I3C component correctly provisioned through GETCAPS configures itself from firmware without a proprietary driver. Modern stacks like Zephyr RTOS expose these CCCs directly through their I3C API, which simplifies portability across STM32, Nordic nRF, and NXP i.MX RT.

In-Band Interrupts (IBI) and hot-join

In-Band Interrupts (IBI) are a mechanism that allows a slave to signal an event to the master without a dedicated physical INT line, with the slave briefly taking control of the bus to emit an interrupt message. This feature frees up valuable GPIO pins on the microcontroller and substantially simplifies the PCB routing of a multi-IMU sensor hub.

In a classic I²C design with eight MEMS sensors, each part needs its own INT line, eight dedicated GPIOs. On an STM32H7 in an LQFP100 package, that consumes nearly ten percent of the usable pins. With IBI, those eight GPIOs disappear: each slave signals its data-ready state, threshold detection, or alert condition directly on SDA, via a time-arbitrated protocol orchestrated by the master.

Hot-join completes the picture. An I3C component can join an active bus in production without a power cycle, unlocking modular architectures that would be unworkable in I²C: hot-swappable daughter cards, connector-plugged sensors, or redundant systems with failover without reboot. The hot-join procedure relies on the ENEC / DISEC CCCs to arm or disarm acceptance of new peripherals.

I²C / I3C coexistence on a shared bus

An I3C bus is natively compatible with legacy I²C peripherals, provided three constraints are met: common signalling voltage, pull-ups sized for the slowest component, and bus speed capped at Fast-mode Plus 1 MHz when the I²C slave is addressed. This coexistence is codified by the Legacy Virtual Register (LVR) of the MIPI standard.

The practical rule: if a mixed design contains at least one 3.3 V I²C slave, the whole bus switches to 3.3 V signalling and I3C-to-I3C exchanges cap at 12.5 MHz SDR (forgoing HDR-DDR). Conversely, a 1.8 V mixed bus needs dedicated level-shifters for 3.3 V I²C slaves, which adds cost and latency. We recommend two clean architectures:

• Mixed 3.3 V bus, SDR only: simple, inexpensive, compatible with every existing I²C MEMS. Effective rate ~10 Mbit/s, enough for most industrial sensors.
• Pure 1.8 V I3C bus, HDR-DDR enabled: maximum performance, suited to high-rate sensor hubs and sensor-fusion applications. Requires a strict hardware inventory (no unisolated 3.3 V I²C parts).

Microcontroller vendor documentation consistently references the MIPI I3C Basic v1.1.1 specification as the normative baseline, and modern software stacks follow that nomenclature.

Industrial use cases: MEMS, sensors, hubs

The industrial use cases for I3C are three families: inertial MEMS sensor hubs for vibration monitoring, dense networks of environmental sensors for metrology and air quality, and power-management systems that finely control multi-rail PMIC converters. All three share a need for bandwidth beyond I²C without the routing complexity of SPI.

In industrial vibration monitoring, an IMU like the STMicroelectronics LSM6DSO32X samples at up to 6.66 kHz on six axes, producing about 40 ksamples/s of 16-bit data, a raw protocol-agnostic load of about 640 kbit/s. On an I²C Fast-mode Plus bus at 1 MHz, occupancy exceeds 70 percent for a single sensor: chaining eight IMUs is impossible without saturation. On I3C SDR at 12.5 MHz, the same sensor uses less than 6 percent of the bus, and the eight-IMU hub architecture stays comfortably below 50 percent with margin for IBIs and configuration.

For environmental sensors, the value lies mostly in coexistence: the Bosch BME688 (temperature, humidity, pressure, gas), for example, only offers I²C and SPI interfaces according to Bosch Sensortec, so on a mixed bus it sits as a legacy I²C slave declared in the LVR, next to native I3C sensors. Routing such a bus follows the signal-integrity rules documented in our guide on high-speed PCB design.

In power management, PMICs that integrate an I3C interface expose their configuration registers through it to drive startup sequencing, rail telemetry, and protection alerts. IBI nicely replaces the traditional PG (Power Good) line multiplexed across rails, and hot-join unlocks architectures with hot-swappable daughter cards in production.

When to migrate from I²C to I3C: decision criteria

The decision to migrate from I²C to I3C requires evaluation of five objective criteria. A single positive criterion rarely justifies the switch; two or three criteria make the migration profitable over the product life cycle.

1. Saturation of the existing I²C bus: if occupancy exceeds 50 percent in Fast-mode Plus at 1 MHz, I3C SDR immediately frees a factor-10 headroom.
2. Recurring address conflicts: more than two identical sensors force a TCA9548A multiplexer in I²C, whereas I3C dynamically assigns addresses without additional hardware.
3. GPIO shortage for INT lines: beyond four sensors with physical interrupts, the GPIO savings via IBI justify the migration.
4. Hot-join required in production: hot-swappable daughter cards, replaceable sensors, and modular architectures demand I3C.
5. I/O power constraint: 1.8 V push-pull signalling clearly cuts dynamic power versus 3.3 V I²C open-drain, which is critical for battery-powered products.

Conversely, sticking with I²C stays sensible in three cases: a BOM locked by a client (aerospace or automotive standards), an entirely legacy sensor ecosystem with no I3C version available, or an end-of-life product where firmware investment no longer pays back. Our default recommendation for any new sensor design is to include I3C in the specification, even if that means starting with pure SDR mode and enabling HDR-DDR later through a firmware revision.

I3C design pitfalls to anticipate

Six recurring pitfalls deserve attention from the architecture phase. Most are easy to avoid with a checklist, but cost a PCB respin or two weeks of firmware debug if they slip into production.

• 1.8 V / 3.3 V signalling mismatch: mixing an I3C MEMS at 1.8 V with a 3.3 V microcontroller without a dedicated level-shifter cooks the ESD protections of the sensitive part. Always check VIL/VIH in the datasheet, not only protocol compatibility.
• Mis-placed single pull-up: unlike I²C, the I3C pull-up must tie to the effective signalling rail (1.8 V or 3.3 V depending on mode), not blindly to VCC. A pull-up to 3.3 V with 1.8 V slaves creates spec violations invisible on a classic scope.
• Missing GETCAPS before HDR-DDR: enabling HDR-DDR without verifying that all bus slaves support it causes sporadic lockups. The discipline is to query GETCAPS at init and then pick the fastest mode the set has in common.
• Hot-join not disarmed in production mode: leaving hot-join enabled in production on a sealed bus degrades EMC robustness (an ESD event can trigger a phantom join attempt). Disarm via DISEC after initial enumeration.
• Misread IBI priority: IBIs are prioritised by dynamic address, not by business criticality. Assign low addresses to critical sensors at ENTDAA time.
• Forgotten LVR (Legacy Virtual Register) for mixed components: a legacy I²C slave not declared in the LVR is seen as an I3C candidate, which corrupts ENTDAA. Always provision the list of legacy slaves in the master driver.

We maintain an internal I3C schematic-review checklist, aligned with the MIPI I3C Basic v1.1.1 specification. This checklist is shared during a 30-minute free audit for projects that go through our electronic design firm. For deeper protocol context, our English bus guides cover the I²C bus, the SPI bus, and the UART bus, and the rest of our analyses are listed on the English blog.

Bottom line

I3C is the right default for any new high-rate sensor design, provided the team treats it as a measurement-driven migration rather than a drop-in replacement. Below are three takeaways for an I²C-to-I3C migration.

• Pick SDR first, HDR-DDR later: 12.5 Mbit/s SDR covers most sensor-hub needs, and HDR-DDR adds integration risk.
• Treat pull-up sizing as a first-class signal-integrity decision: despite the I3C marketing simplification, the single SDA pull-up still has to match the rail and the worst-case capacitance.
• Disable hot-join in production: keep ENEC during commissioning, push DISEC before the firmware locks the device tree, and document the LVR list of legacy I²C parts so ENTDAA stays clean.

FAQ: I3C bus in electronic design

This I3C FAQ collects the recurring questions asked during the architecture phase. The answers rely on the MIPI I3C Basic v1.1.1 specification.

Is I3C really compatible with my existing I²C parts?
Yes, under three conditions: common signalling voltage (3.3 V if you mix legacy I²C), bus in SDR mode at most when an I²C slave is addressed, and declaration of the legacy part in the master driver's Legacy Virtual Register (LVR). With these in place, a mixed bus works natively.

What is the concrete difference between I3C SDR and HDR-DDR?
SDR samples on a single clock edge at 12.5 MHz for 12.5 Mbit/s effective. HDR-DDR doubles the cadence by sampling on both edges for 25 Mbit/s. HDR-DDR requires every slave on the bus to support it, verified via the GETCAPS CCC at init.

When should I pick SPI over I3C for a high-rate sensor?
SPI stays preferable if you have a single point-to-point sensor at very high throughput (40 Mbit/s and above), or if your microcontroller lacks a native I3C controller. I3C wins as soon as you address more than two sensors and want IBI or hot-join.

Do STM32 microcontrollers support I3C?
Yes for recent STM32H5, STM32U5, and STM32H7 families, which integrate an I3C controller compliant with v1.1.1 and support SDR plus HDR-DDR. The STMicroelectronics HAL exposes the main CCCs and Zephyr provides a portable cross-vendor driver. Older STM32F4/F7 families stay I²C-only.

Do I need two pull-ups like in I²C?
No, a single pull-up on SDA is enough on a pure I3C bus. SCL is actively push-pull-driven by the master. If the bus is mixed with legacy I²C slaves, a pull-up on SCL can stay useful to preserve backward compatibility, but it is not mandatory on a native I3C bus.

Does I3C really consume less than I²C?
Yes, on a typical bus. The reasons: 1.8 V signalling instead of 3.3 V (dynamic power divided by three for the same capacitance), active push-pull which removes resistive losses in the pull-ups, and higher bit rates which cut the bus-active time for the same data volume.

Related articles

To go further on your embedded communication project and the associated PCB design:

• I²C bus: operation and best practices: the predecessor to I3C, still relevant for legacy designs.
• SPI bus: full-duplex high-speed alternative: useful comparison with I3C on point-to-point MEMS sensors.
• UART bus: asynchronous serial communication: completes the serial-protocol family for embedded products.
• MEMS accelerometers: integration guide: typical use case for a high-rate I3C bus.
• High-speed PCB design: signal integrity on fast buses, including I3C HDR-DDR.