MIPI I3C and I3C Basic Frequently Asked Questions

Yes, a number of companies have released products which feature integrated I3C Master and I3C Slave support. Other companies offer IP blocks and associated verification software for adding I3C Bus support into various integrated circuit designs. Some companies also offer protocol analyzers and verification hardware to help analyze I3C Bus traffic for testing and development.

Since this document cannot provide a comprehensive list of such products, those who are interested in learning more about products that support or enable I3C should contact MIPI Alliance.

I3C offers dynamic address assignment, Slave-initiated communication, and significantly higher communication speeds than I²C.

MIPI I3C is a serial communication interface specification that improves upon the features, performance, and power use of I²C, while maintaining backward compatibility for most devices.

MIPI I3C Basic is technically identical to MIPI I3C, except with a reduced feature set and RAND-Z licensing.

Yes, I3C allows for multiple Masters on the same Bus. I3C has one Main Master that initially configures the Bus and acts as the initial Current Master. Optionally, the Bus can have one or more Secondary Master Devices that initially act as Slaves. Any Secondary Master Device can request to become the Current Master. Once the Current Master agrees to the request, and transfers Current Master control (‘Mastership’) to a given Secondary Master Device, then that Device becomes the Current Master.

The I3C Bus is limited to around a dozen devices.

The main purpose of MIPI I3C is threefold:

1. To standardize sensor communication,
2. To reduce the number of physical pins used in sensor system integration, and
3. To support low power, high speed, and other critical features that are currently covered by I²C and SPI.

MIPI I3C’s purpose is now widening to cover many types of devices currently using I²C/SMbus, SPI, and UART.

The CCCs are the commands that an I3C Master uses to communicate to some or all of the Slaves on the I3C Bus. The CCCs are sent to the I3C Broadcast address (which is 7’h7E) so as not to interfere with normal messages sent to a Slave. In other words, CCCs are separated from the standard “content protocol” used by normal messages, such as Private Write and Read transfers (in SDR Mode).

The CCCs are used for standard operations like enabling/disabling events, managing I3C‑specific features, and other Bus operations. CCCs can be either Broadcasted (i.e., sent to all Devices on the I3C Bus), or else Directed at specific Devices on the I3C Bus. All CCCs (i.e., the command numbers themselves) are allocated by MIPI Alliance, and some are reserved for specific purposes including MIPI Alliance enhancements and other extensions.

Yes, both I3C and I²C can share the same bus. For details, see question above regarding I3C backward compatibility.

I3C has two signal lines: Data (SDA) and Clock (SCL).

Generally, a Virtual Slave is a function of a single physical Device that represents multiple I3C Slaves on the I3C Bus, such that the I3C Master can address each of those Slaves independently.

In the simplest form a Virtual Slave could be one of a set of several Slave Devices all integrated into the same physical package, sharing a common set of pins connecting them to an I3C Bus.

In a more advanced form, a Virtual Slave could act as one of several virtualized functions presented by a highly‑integrated Device that stores a different Dynamic Address for each function. Depending on the implementation, such virtualized functions might share configuration information, and might return the same values for some CCCs.

Examples could include Bridging or Routing Devices, as well as other types of Devices that expose multiple functions and use shared Peripheral logic. I3C v1.1 defines several new capabilities and features for such Virtual Slaves.

See the I3C v1.1 Specification at Section 5.1.9.3.19, and the System Integrators Application Note for I3C

Yes. I3C v1.1 defines requirements, expectations, and configuration for Routing Devices, which enable the creation of multiple Routes across I3C Buses. A Routing Device enables more advanced Bus topologies and requires buffers or queues to handle transactions across each Route.

The Routing Device contains a Control Function, presented on the I3C Bus as a Virtual Slave. The Master configures the Routing Device by sending the SETROUTE CCC to the Control Function. Routes to other I3C Buses are treated as downstream targets, each of which generally has a Target Function which is also presented as a Virtual Slave with its own Dynamic Address. Transactions are sent to the Route’s Target Function via its Dynamic Address, and the Routing Device manages the communications on the downstream I3C Bus.

See the I3C v1.1 Specification at Section 5.1.9.3.20, and the System Integrators Application Note for I3C

All three are special, in-band methods that allow the Slave to notify the Master of a new request or state, without having to wait for the Master to query or poll the Slave(s). The term ‘in-band’ refers to doing this via the I3C Bus wires/pins themselves, rather than using methods requiring extra wires/pins.

• In-Band Interrupt (IBI): An IBI request is used by a Slave to notify the Master of a new state or event. If the Slave so indicates in the BCR, then an IBI may include one or more following data bytes. A Slave can only use IBI if it has indicated the intent to do in the BCR.
  If the Slave indicates it will send data with an IBI, then it is required to always send at least 1 byte, called the Mandatory Data Byte (MDB). Starting with I3C v1.1, the MDB is coded following certain rules. Any data after the MDB is a contract between Master and Slave.
• Hot-Join (HJ): An HJ request is used only by an I3C Slave that hasn’t yet been assigned a Dynamic Address and is attached or awakened on the I3C Bus after the Main Master has intialized it. HJ uses a fixed address reserved for this purpose only. The Master will recognize this fixed address and then initiate a new Dynamic Address Assignment procedure. Note that the HJ request cannot be used by a Slave until it has verified that the I3C Bus is in SDR Mode, as explained in the specification.
• Mastership Request (MR): A Secondary Master (including the Main Master, once it has given up initial Mastership) sends an MR when it wants to become Master of the I3C Bus. If the Current Master accepts the MR, then it will issue a GETACCMST CCC to hand control off to the requesting Secondary Master. It is also possible for the Current Master to initiate mastership handoff on its own, without any Slave initiating an MR, for example when a Seconary Master wants to return control.

The system designer decides whether their system needs more than one Master on the Bus. To provide that flexibility MIPI I3C allows this, but also does not require it. Master handoff is a well defined and controlled mechanism in I3C; if used, it can be relied on.

For most use cases, a Secondary Master is not a required component for an I3C Bus. If your Main Master has all the capabilities and features that you need, and if your use of the I3C Bus wouldn’t benefit from having multiple Master-capable Devices, then you might not need a Secondary Master.

Examples where Secondary Masters are useful:

1. Debug controller, if present, would be a Secondary Master
2. A sensor hub or other offload device can be used to continue operating during periods when the Host processor is in deep sleep (i.e., to save power)
3. The system can switch between standalone use (such as IoT devices) and connected uses (perhaps a USB-to-I3C cable is attached to take over temporarily)

Note that Devices such as MCUs will usually be able to operate as fully-fledged Slaves, as fully-fledged Main Masters, and as Secondary Masters (i.e., Devices that come up as Slaves but can become Masters), depending solely on the particular needs of the given system. They can simply be configured for the Bus they are on by the firmware.

Once assigned an I3C Dynamic Address, an I3C Slave normally retains it until the Slave is de-powered. However, an I3C Slave will lose its I3C Dynamic Address through the RSTDAA Broadcast CCC, which resets all I3C Slaves back to their initial I²C state. The RSTDAA Broadcast CCC is not normally used; it would only be used to assign a new Dynamic Address.

An I3C Slave might also lose its Dynamic Address if the Device is reset: for example, pin-reset, full Slave Reset (starting with I3C v1.1), deepest-sleep (power down), etc. In the case of an I3C Device losing its Dynamic Address in non-standard ways, the Hot-Join mechanism is provided to allow the Slave to notify the Master of the event and receive a new Dynamic Address. In cases where the Master has deliberately caused the Slave to lose its Dynamic Address (e.g., by sending the RSTDAA CCC, or by causing a Slave reset), the I3C Master will start a new Dynamic Address Assignment process using the ENTDAA, SETDASA, or SETAASA CCC.

See also Offline Mode for I3C Slaves, where the Devices retain their Dynamic Addresses through a power‑down or deepest‑sleep cycle.

The coding and framing details for CCCs have been changed or extended, in three important areas:

1. Direct Write/Read Commands: In I3C v1.0, Direct CCCs were either Direct Read Commands (Direct GET CCC) or Direct Write Commands (Direct SET CCC). I3C v1.1 adds an additional Direct Write/Read Command (Direct SET/GET CCC) form: a Direct Write immediately followed by a Direct Read with the same Command Code; this form is used for alternatively writing to, and then reading data from, one or more specific I3C Slave Devices. The Direct Write/Read Command uses the Direct CCC framing model per Section 5.1.9.2.2.

Example: An I3C Master might use the MLANE CCC (Section 5.1.9.3.30) to configure an I3C Slave Device to use a specific Multi-Lane configuration using a Direct SET CCC, followed by a Direct GET CCC to read back the active Multi-Lane configuration and confirm that it was selected for operation.  Using both forms of Direct SET CCC and Direct GET CCC within the same SDR frame is considered a Direct SET/GET CCC.

2. Defining Byte for Directed CCCs: In I3C v1.1, some Directed CCCs add support for a Defining Byte.
   
   1. In CCC framing for SDR Mode, the coding of the initial CCC is: S, 7’h7E, CCC_byte, Defining_Byte, Sr, Slave_Addr, ....
      
      For more framing details for SDR Mode, see Table 15 in Section 5.1.9.1.
   2. In CCC framing for HDR Modes, the Defining Byte is sent in the HDR-x CCC Header Block of type Indicator. This framing element is defined differently for each HDR Mode; for more framing details, see Table 53 in Section 5.2.1.2.1.

Depending on the particular CCC, this Defining Byte can be used in several possible ways:

• It might define a register/code to set, either with or without additional per-Slave info
• It might select a particular register/code to read, from among several available for that CCC
• It might indicate one of several completely different sub-commands, each of which might be either required or optional, as needed for the particular CCC definition and use case.

Example: When used with the MLANE CCC, a Defining Byte selects a sub‑command. One sub-command might be used to read the available Multi-Lane capabilities for an I3C Slave Device, as a Direct GET CCC; another sub-command might be used to either configure an I3C Slave Device to use a specific Multi-Lane configuration, or read back the same active Multi-Lane configuration, as either a Direct GET CCC or a Direct SET CCC. For this use case, each Defining Byte has a different purpose and a different, specific data format.

Example: A Defining Byte for the GETCAPS CCC (see Section 5.1.9.3.19) selects among several different capabilities areas, to read from an I3C Slave Device as a Direct GET CCC. For this use case, the Defining Byte may also indicate different formats for the data message returned by the I3C Slave Device.

For some new Direct CCCs defined in I3C v1.1, a Defining Byte is required.

3. New Optional Defining Bytes: In I3C v1.1, some CCCs that had no Defining Byte in I3C v1.0 now have optional Defining Bytes to extend their functionality and support other new behaviors. If the I3C Master sends the CCC without the Defining Byte then the original functionality or behavior occurs, but if the CCC is sent with the Defining Byte then the optional extended functionality or new behavior is accessed (see Section 5.1.9.2.2).

Many Direct GET CCCs that allow optional Defining Bytes also have a method for indicating whether any additional Defining Bytes are supported. This support would be indicated in the data message returned by the Direct version of a particular CCC (which might be the same CCC) when sent without a Defining Byte. This allows an I3C Master to query an I3C Slave Device to determine whether this capability is supported. The particular CCCs that allow optional Defining Bytes are defined in version 1.1 of the I3C Specification (see Section 5.1.9.3). Additionally, for I3C Slave Devices that support such Direct CCCs and also support any optional Defining Bytes, a Defining Byte value of 0x00 generally results in the same behavior as when no Defining Byte is sent.

While Defining Byte support for such Direct GET CCCs is generally optional, certain Defining Byte values are required or strongly recommended for certain use cases, or when used in conjunction with other features or capabilities. Such Direct CCCs list these conditions or recommendations, in addition to any changes in the format of the data message that might be returned when a Defining Byte is used.

Example: In I3C v1.1, an I3C Master can use the GETSTATUS CCC (see Section 5.1.9.3.15) to determine the operational status of an I3C Slave Device. All I3C Slaves support the use of GETSTATUS without a Defining Byte. But if an I3C Slave also supports the GETSTATUS CCC with any optional Defining Bytes, then the I3C Master may also do either of the following things:

• Send the Direct GET GETSTATUS CCC with a Defining Byte of 0x00, to return the same data message as if no Defining Byte were used;
• Send the Direct GET GETSTATUS CCC with any other Defining Byte value listed in Table 24. Any I3C Slave that supports that particular Defining Byte is required to ACK the CCC and return an appropriate data message for that Defining Byte (i.e., not the standard Slave Status). For example, if a Defining Byte value of 0x91 (“SECMST”) is supported, then using this Defining Byte would request the Slave to return alternate status information related to the Slave’s Secondary Master capabilities.

For most use cases, custom CCCs (including the command codes that are defined for Vendor or Standards use, see Q1.31) should generally be used as configuration or control commands, sent from an I3C Master to one or more I3C Slave Devices. Using custom CCCs for larger data transfers is not recommended.

When considering the practical concerns of implementing support for custom CCCs in an I3C Slave, it is important to note that CCCs in I3C are generally used as shorter messages that are separated from the standard content protocol (i.e., Write and Read transfers in SDR Mode, or any HDR Modes) and are not intended to interfere with normal messages sent to a Slave (see Q1.20).

Additionally, since the Command Code and Defining Byte for CCCs are sent to the I3C Broadcast Address (i.e., 7’h7E) and rely on a special ‘modality’ that must be observed by all Slaves, handling for custom CCCs might need to be implemented differently within the Slave.

With these considerations in mind, implementers should consider using custom CCCs for special purposes, taking advantage of the CCC flows and their separation from the content protocol, to affect changes to the flow or meaning of transfers that are used in their content protocol. By contrast, transfers within their content protocol (such as Write or Read transfers in SDR Mode, or any HDR Modes) should be used for data‑intensive transactions. In most cases, custom CCCs should enable new mechanisms for configuring or controlling a Slave Device, while transfers in their content protocol should be used for data transfers between a Master and a Slave.

The following examples are provided as guidance for custom CCC definitions:

• Configuration commands that switch between various supported formats of index or selection that might be used in a Write command, or the first phase of a two-phase Write+Read command
• Configuration commands that send a directed mode change to particular Slaves, or broadcast mode changes to all Slaves that support a particular capability or feature (if applicable)
  • Note that custom Broadcast CCCs (i.e., for Vendor or Standards use) should be used with caution, as these are received by all Slaves on the I3C Bus, and various Slaves might handle such CCCs differently (i.e., by not using a common interpretation; see Q1.31 for guidance).
• Control commands that switch between multiple endpoints within a Slave, using a multiplex model that chooses how and where a standard Write transfer might be directed and processed, or from where a Slave might source the data message for a Read transfer
  • In this case, the custom CCC acts as a command to the multiplexor logic.
  • However, such a multiplex model means that only one endpoint at a time can be selected for active use, which might present a limitation for the use case, and might restrict the modality for using such a Slave.
• Special messages sent only to the Slave hardware (i.e., the Peripheral logic) whereas the data‑intensive transfers in the standard content protocol might be implemented via software or other agents that connect to the Peripheral logic, and would not need to see such special messages
  • In this case, the Peripheral logic would be expected to offer a quick response due to CCC framing, so a shorter CCC message would offer rapid response due to the expectations based on capabilities in Peripheral logic, versus waiting for software or other agents to respond, which might lead to delays.
  • By contrast, an implementation that used Peripheral logic with software to respond to Direct GET CCCs might not be capable of successfully responding to the first such attempt, and would rely on ideal timing conditions to successfully respond to subsequent attempts.
  • Note that this might only apply to implementations that relied on software, versus implementations that handled custom CCCs natively (i.e., entirely within hardware).
• Commands that change modes to initialize new functions or enable a new modality, which might change the interpretation of standard transfers for the content protocol (e.g., firmware download, key exchange)
  • For example, a custom CCC might act as a method for entering or exiting the modality in which the standard transfers are applied to a new purpose (such as transferring new firmware contents or key data). Upon exiting the modality, the new function of the Slave would be applied based on the data transferred during the modality, and the standard content protocol would be used for subsequent operations with the new function.

For other use cases that do not generally follow these guidelines, or use cases that rely on larger message lengths for data-intensive transactions, a content protocol that primarily uses standard transfer commands (i.e., not CCCs) is strongly recommended. Using custom CCCs for data-intensive transactions on the I3C Bus might cause implementation issues for various Slave Devices that are based on Peripheral logic and use “software” to handle the response for custom Direct GET CCCs. Additionally, using custom CCCs might introduce integration issues or other platform power concerns that might only appear on I3C Buses with other Slave Devices which would not have been fully optimized to ignore such custom CCCs, or with other Slave Devices that relied on different interpretations of custom CCCs and might not understand a particular use of SETBUSCON for the use case (as defined in Q1.31). For such situations, it might not be possible to predict these issues in advance, until full system integration testing is performed.

Note that higher-level use cases could use a mix of Write/Read transfers for the content protocol, along with custom CCCs for targeted configuration and control functions, which would take advantage of the strengths of CCCs as well as the ways in which CCCs are well-suited for effective changes to control, modes or operational parameters of an I3C Slave Device. For some specific aspects custom CCCs might be recommended, whereas other use cases involving multiple endpoints might be better served with Virtual Slave capabilities (see Q1.34 for more details) if such endpoints would need to be used simultaneously.

Implementers seeking more specific guidance or recommendations should contact the I3C WG within MIPI Alliance for assistance.

Note: This question does not apply to I3C Basic v1.0.

Yes. The I3C Bus supports an optional Timing Control mechanism with multiple timing modes. One timing mode is synchronous (from the synchronized timing reference) and four modes are asynchronous (Slave provides timestamp data). All I3C Masters are expected to support at least Async Mode 0.

• Synchronous: The Master emits a periodic time sync that allows Slaves to set their sampling time relative to this sync. This may be used in conjunction with one of the Asynchronous modes.
• Asynchronous: The Slaves apply their own timestamps to the data at the time they acquire samples, permitting the Master to time-correlate samples received from multiple different Slaves or sensors.

There are four types (timing modes) of asynchronous time controls:

• Async Mode 0: Basic timing mode that assumes that a Slave has access to a reasonably accurate and stable clock source to drive the time stamping – at least accurate for the duration of the time it has to measure (i.e., from event to IBI). A set of counters, in conjunction with IBI, are used to communicate time stamping information to the Master.
• Async Mode 1: Advanced timing mode extends the Basic mode by using some mutually identifiable bus events, like I3C START.
• Async Mode 2: High‑precision timing mode that uses SCL falling edges (for SDR and HDR-DDR modes) as a common timing reference for Master and Slave. A burst oscillator is used to interpolate the time between a detected event and next SCL falling edge. For HDR-TSL and HDR-TSP modes, this timing mode uses both SDA transitions and SCL transitions as timing references.
• Async Mode 3: Highest-precision triggerable timing mode that supports precise time triggering and measurement across multiple transducers applications like beam forming.

By default, there is no limit to the maximum message length. To reduce Bus availability latency across multiple Slaves, the I3C Bus allows negotiating for maximum message lengths between Master and Slave. Further, Read terminate is possible from the Master, to allow regaining control of the Bus under a long message.

Bridge Devices are expected to enable an I3C Bus to be bridged to other protocols, such as SPI, UART, etc. A CCC is defined to enable bridging Devices, where the Master knows in advance that certain Devices are bridges.

All I3C Slaves must be tolerant of the 12.5 MHz maximum frequency, and all Slaves must be able to manage those speeds for CCCs. But Slaves may limit the maximum effective data rate for private message – either write, read, or both.

Yes. A pair of Directed and Broadcast CCCs is available for the Master to enter/exit the test modes.

Yes, the I3C Bus has elaborate error detection and recovery methods. Seven Slave error types (S0 to S6) and three Master error types (M0 to M2) are defined for SDR Mode, along with suggested recovery methods. Similarly, a set of errors are defined for each of the HDR Modes.

Note: This question does not apply to I3C Basic v1.0.

The CRC transmission ends at bit 6 (counting down from 15), but bit 5 allows High-Z.

The STOP can be issued anywhere the Slave is not driving the SDA during SCL High. It may not be appropriate to do so in terms of completion of a message. But ACK and completed transaction do not belong together in I3C.

The I3C Bus protocol supports a mechanism for Slaves to join the I3C Bus after the Bus is already configured. This mechanism is called Hot-Join. The I3C Specification defines the conditions under which a Slave can do that, e.g., a Slave must wait for a Bus Idle condition.

Only if they have a way to turn off the Hot-Join feature. Hot-Join is not compatible with I²C masters, so Hot‑Join would have to be disabled for the Slave to be used on a legacy I²C bus. The disabling of the Hot‑Join feature should be done via some feature that is not part of the I3C protocol (i.e., not via the DISEC CCC), since an I²C master does not support the I3C protocol.

This topic is extensively explained in the I3C v1.1 Specification at Section 5.1.9.3.18.

Please see the I3C v1.1 Specification at Section 5.1.3.1.

At Section 5.1.9.2.3 the I3C v1.1 Specification states: “I3C mandates a single-retry model for Direct GET CCC Commands.” Based on this statement, adopters have a general notion that the Master is required to retry once for the Directed GET CCCs if the Slave NACKs for the first time. This may not be applicable for other “read” Directed CCCs (such as RSTACT, MLANE, vendor read, etc.) that are not defined for dedicated Read CCCs (i.e., CCCs that have names of the form GETxxx).

These errors should be recovered by STOP. But vendors can choose to recover from these errors when seeing a Repeated START. Note that STOP is the second step of escalation after Repeated START recovery.

Although MIPI Alliance strongly recommends true support of Slave Reset, such that a Master can fully reset a Slave chip when needed, it is not required. Full Chip Reset allows replacement of the SRSTn trace that would normally be used to reset a Device.

The minimal reset is a reset of the I3C peripheral, at least to a level that will allow a ‘stuck’ I3C peripheral to start working again. How much of a reset that requires is up to the Slave Vendor; for example, it could be handled by an internal interrupt which would allow firmware/software in the Slave to handle the reset.

In 2019 the Sensor Working Group was renamed to “I3C Working Group”. Its member companies often change, but the following is a recent representation: Intel, Invensense, Lattice, NXP, Prodigy, Qualcomm, Robert Bosch, STMicroelectronics, Synopsys, and Sony.

Not directly, for a couple of reasons:

1. The I3C Bus works with push-pull modes (in addition to the open drain for some transfers), and
2. Much higher speeds. Most such devices are quite limited in speed, because of the lag effect of changing states on SCL and SDA due to both series-resistance and assumptions about open-drain.

Long wire approaches are being evaluated for a future version of the I3C Specification.

I3C Slaves are only allowed to drive the Bus under certain situations. Besides during a read, and when ACKing their own address, they may also drive after a START (but not Repeated START). After a START, the I3C Bus reverts back to open-drain pull-up resistor mode; thus, the Slave that drives a low value (logic 0) would win.

MIPI arranges a particular I3C Interoperability Workshop event in response to requests from its membership. 

While this could change in future, the minimal requirements to date have been the availability of a board with an I3C Device that can connect to other Devices via the three wires SDA, SCL, and GND. It’s also useful to have software (e.g., running on a laptop connected to the board and I3C Device) to interactively view transmitted and received bus communications, but this might not be required for Slaves.

Currently there are solutions working at 3.3V and 1.8V.

No, there are no pending errata at this time.

There are no immediate plans to revise I3C v1.1, however the MIPI I3C WG meets regularly and is considering proposals.

Note: This question does not apply to I3C Basic v1.0.

Yes. This is allowed such that the ODR (Output Data Rate) rate controls the In-Band Interrupt (IBI) rate, and the Async Mode timestamp on the IBI indicates how long ago the sample was collected.

Note: This question does not apply to I3C Basic v1.0 and I3C v1.1.

Newer versions of the I3C Specification define a new t_IDLE minimum value of 200 µs, since that is sufficient for all valid uses. I3C v1.0 devices may choose to support that smaller delay now. I3C Basic v1.0 and I3C v1.0 already support a t_IDLE minimum value of 200 µs.

The I3C Slave may choose to detect 100 µs without an SCL edge. If that happens, it can abandon the Read and release SDA to avoid a Bus hang when the Master restarts.

In I3C v1.1, use of this CCC is expanded to support Bridging Devices with Dynamic Addresses, enabling multiple Bridging Devices on the same I3C Bus. The context of this CCC is also redefined, such that a Bridging Device is now one of several types of Devices that expose or present Virtual Slaves. Bit[4] of the Bus Configuration Register (BCR) now indicates Virtual Slave capabilities.

For bridged Slaves that are enabled by a Bridging Device, I3C v1.1 clarifies the use of other CCCs (such as SETMRL) that address a bridged Slave. I3C v1.1 also clarifies that the SETBRGTGT CCC must be used to change the Dynamic Address of a bridged Slave (not the SETNEWDA CCC).

See the I3C v1.1 Specification at Sections 5.1.1.2.1, 5.1.9.3.17, and 5.1.9.3.19; and the System Integrators Application Note for I3C

The standard GETMXDS CCC itself was not changed in I3C v1.1, though the definition of t_SCO was clarified. However, the GETMXDS CCC now supports a Defining Byte value that allows the return of other forms of information. With no Defining Byte (and with a Defining Byte with value 0), the GETMXDS CCC behaves exactly as the original GETMXDS CCC did in I3C v1.0.

Interoperability Workshops will ultimately follow the tests identified in the I3C CTS, as it nears completion.

The I3C WG is currently developing a CTS for I3C v1.1, for early 2020 release.