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

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 has become the natural evolution path in 2026.

At AESTECHNO, with over 10 years designing embedded boards around STM32 and Nordic nRF microcontrollers, we have been integrating this protocol on industrial products since the first I3C-capable MEMS shipped (STMicroelectronics LSM6DSO32X, Bosch BMI323). We have found, per Bosch Sensortec, that modern MEMS sensors saturate the timing budget of an I²C Fast-mode Plus bus as soon as you exceed 3 to 4 axes sampled at kHz rates. The new bus lifts that 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 we have hit on our 2024 and 2026 projects.

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, per Intel — which sits on the MIPI committee and implements the standard on its server and embedded platforms — three needs that became critical from 2024 onwards: the densification of MEMS sensors around microcontrollers (up to 32 IMUs on a single hub in recent architectures), 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.

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 by a factor of three to five 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.

At AESTECHNO, we found that 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 MIPI I3C Basic specification. SDR mode (Single Data Rate) reaches 12.5 Mbit/s and covers 90 percent of sensor use cases. The HDR (High Data Rate) modes double or triple that rate for audio streaming, imaging, or multi-axis inertial data sampled at several kHz.

The HDR-DDR mode is, as noted by Lattice Semiconductor — a vendor of commercial I3C hubs — 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 two or three bits per transition to reach 33 to 40 Mbit/s effective, at the cost of additional hardware complexity that limits adoption to multimedia SoCs.

Mode	Effective rate	Typical use case
SDR	12.5 Mbit/s	MEMS sensors, environmental sensors, PMIC, EEPROM
HDR-DDR	25 Mbit/s	6- or 9-axis IMU at 6.4 kHz, dense sensor hubs
HDR-TSL	33 Mbit/s	MEMS audio streaming, sensor buffering
HDR-TSP	40 Mbit/s	Multimedia SoCs, high-rate display interfaces

For our projects, 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 saturated 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).

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. One third of multi-IMU I²C designs require, per Renesas — which documents the problem in its application notes on sensor hubs — 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 our practice on industrial sensor-hub designs, we observed that 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.

At AESTECHNO, on a recent project we deployed both mechanisms on an industrial vibration-monitoring platform with eight connector-plugged sensors on a backplane, and we measured the resulting MCU-pin budget on a logic analyser during integration. The GPIO savings on the MCU allowed us to pick a more compact part, and hot-join commissioning cut field intervention time by a factor of two.

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. On our projects we favour 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 95 percent of 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).

Per Microchip, the PIC32CM Ls MCU family natively supports dynamic mode-switching on the I3C bus, which simplifies hybrid designs. 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 6.4 kHz on six axes, producing 38 ksamples/s of 16-bit data, a raw protocol-agnostic load of 612 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 Bosch BME688 family (temperature, humidity, pressure, gas) has been shipping in a native I3C version since 2024. Per Bosch Sensortec, a metrology network of twelve BME688 parts on a single I3C bus fits within a 100 ms timing budget, versus 800 ms minimum on an I²C equivalent. On a recent client project, we supported a client with an indoor air-quality metrology product certified CE RED, with routing compliant with the signal-integrity rules documented in our guide on high-speed PCB design.

In power management, modern PMICs (Qualcomm PM8350C, Renesas RAA215300) expose their configuration registers through I3C 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 cuts dynamic power by a factor of three to five versus 3.3 V I²C open-drain — 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 launched after 2024 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.

Design pitfalls and AESTECHNO lessons learned

Our projects since 2024 are the source of a list of six recurring pitfalls that 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 and with the lessons learned from our STM32, Nordic, and NXP integrations. This checklist is shared during a 30-minute free audit for projects that go through our electronic design house.

FAQ: I3C bus in electronic design

This I3C FAQ collects the recurring questions our clients ask during the architecture phase, drawn from a dozen sensor-hub and power-management projects since 2024. The answers rely on the MIPI I3C Basic v1.1.1 specification and on our own field report from these deployments.

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, by a factor of three to five 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.