Checking Legacy I2C Device Compatibility on an I3C Bus

I3C can support selected legacy I2C devices on a shared bus, but that compatibility has electrical and timing conditions. A device that works on a conventional I2C bus is not automatically suitable for every I3C configuration. Review each legacy target before enabling faster traffic or changing the bus controller.

Identify the compatibility assumptions

The MIPI I3C general-topics application note hosted by NXP discusses legacy-device spike filtering and methods for assessing whether faster I3C transfers are ignored appropriately. The assessment belongs to the actual device and supported bus mode.

List every target, static address, voltage range, clock-stretching behavior, filtering specification, and bus mode. Include buffers, switches, and level translators because they also affect the electrical path.

Review the controller configuration

Confirm how the controller is informed about legacy devices and which timing restrictions it applies. Check the relevant I3C version and the modes supported by the controller and targets.

Do not assume that an address scan establishes full compatibility. A target may acknowledge a slow transaction yet react incorrectly to unrelated faster traffic that follows.

Test mixed traffic deliberately

Read and write the legacy device using a controlled transaction sequence, then interleave representative I3C traffic. Include the busiest supported traffic pattern, since an isolated transaction may not expose a state-dependent interaction. Verify the legacy device’s registers and state afterward, including any commands with persistent side effects.

Use test registers or reversible settings where available. A compatibility experiment should not accidentally change a sensor’s configuration without detecting that change.

Observe the electrical behavior

Capture clock and data at the legacy target while the mixed bus operates. Check levels, edge behavior, and any unexpected target drive. A bus analyzer’s successful I3C decode does not establish that the legacy target ignored the same waveform.

For example, a level translator designed around open-drain operation may need a separate suitability review when the bus uses push-pull phases. Its presence can invalidate assumptions made from the endpoint data sheets alone.

Repeat startup, reset, and target power-state combinations that the product permits. Confirm that an uninitialized or partially powered target does not hold the bus or interpret traffic differently from its configured state.

Save the device compatibility table, controller settings, mixed-traffic sequence, register checks, and captures. State exactly which devices and bus modes were validated. Shared SDA and SCL connections are a starting point; the complete electrical path and each target’s behavior determine whether the mixed bus is a supported implementation.