MIPI I3C and I3C Basic Frequently Asked Questions

The official name is MIPI Alliance Improved Inter Integrated Circuit.

MIPI I3C carries the advantages of I²C in simplicity, low pin count, easy board design, and multi-drop (vs. point-to-point), but provides the higher data rates, simpler pads, and lower power of SPI. I3C then adds higher throughput for a given frequency, In-Band Interrupts (from Target to Controller), Dynamic Addressing, advanced power management, and Hot-Join.

The power consumption per bit-transfer in all I3C modes is more efficient than I²C, due to the use of push-pull (vs. Open-Drain) and strong Pull-Up signaling.

Further, I3C can save considerable device power through higher data rates (because the device can be put back to sleep sooner), built-in configuration and control (without intruding on the main communication protocols), In-Band Interrupt (IBI) as a low-cost wake mechanism, and the ability for Targets to shut down all internal clocks while still operating correctly on the I3C Bus.

Almost all new features of I3C v1.1 are optional.

However, it should be noted that:

• The formerly optional CCC GETHDRCAPS has been changed to GETCAPS, and its support is required for I3C v1.1 Devices, so as to indicate it is a v1.1 (or later) Device.

• Additionally, it is necessary to support the new RSTACT CCC; as a result, support for a minimal Target Reset is required.

MIPI recommends that Targets consider support of improvement features (such as Flow control for HDR, and Group Addressing), as well as features they likely could use for their application.

MIPI I3C v1.1.1 is an editorial update of MIPI I3C v1.1 that contains no new features or capabilities, but resolves issues, clarifies, and improves on the I3C v1.1 specification.

MIPI I3C v1.1.1 includes:

• Fixes for inconsistencies and other issues that were technical errors in MIPI I3C v1.1 (including
• all issues resolved by Errata 01)
• Clarifications to the requirements and procedures used for Dynamic Address Assignment, Hot-Join Requests and In-Band Interrupts
• Clarifications to Target Error Types TE0, TE5, and TE6
• Improved clarity and fixes for issues in the sections that define CCC flows in HDR Modes (generic as well as HDR Mode–specific)
• Additional clarifications and explanations in some sections that did not fully explain new features and capabilities introduced with I3C v1.1
• Better explanations of I3C Devices that support advanced features, such as composite I3C Devices that present multiple I3C Target roles (i.e., Virtual Targets)
• Additional clarifications concerning the intersection of several of these new features and capabilities when implemented together (i.e., when used in concert in the same I3C Bus with I3C Devices that choose to support several or all such features or capabilities concurrently)
• Limited allowances for flexibility in how certain new features and capabilities could be applied, or which of these new features and capabilities might be regarded as required, optional, or conditionally required per use case
• Improved descriptions for Multi-Lane Device configuration, including clarified requirements for I3C Devices that present multiple Dynamic Addresses and/or support Group Addressing
• Additional diagrams for HDR-BT Mode, including the 1-Lane forms of the structured protocol elements (i.e., Blocks) that are used in HDR-BT transfers, as well as an example of an HDR-BT transfer
• Improved descriptions of error detection and recovery methods, such as Error Type TE0 and Error Type DBR (Dead Bus Recovery)
• Changes to the Multi-Lane signaling of the Header Byte in SDR Mode

Note: With the release of I3C v1.1 this question has been deprecated; it is retained here for reference. See Q3.1, " What is new in I3C v1.1?" (in the section: I3C Versions and Releases) for what’s new in I3C v1.1.

All fixes or Errata for I3C v1.0 have also been applied to I3C v1.1. However, I3C v1.1 has since been superseded by MIPI I3C v1.1.1, which is the newest recommended version of the I3C specification. All fixes for Errata for I3C Basic v1.0 have been incorporated into I3C Basic v1.1.1, which is the newest recommended version of the I3C Basic specification

Based on learning from early implementations, I3C Interoperability Workshops, queries from adopters, and reviews by the I3C WG, this FAQ represents clarifications, improvements that can be implemented by I3C v1.0 Devices or I3C Basic v1.0 Devices, and other guidance for implementers.

Yes, several fixes to MIPI I3C v1.1 have been identified, and MIPI has published these fixes as Errata 01.

These fixes fall into four categories:

1. Resolving inconsistencies in HDR-DDR Mode
   I3C v1.0 and v1.1 did not consistently describe whether an HDR-DDR Data Word was always required for HDR-DDR transactions. Additionally, I3C v1.1 introduced CCC flows in HDR-DDR Mode, which assumed that flows with zero HDR-DDR Data Words were both possible and valid, and it did not always provide appropriate acknowledgement for Target Devices. Errata 01 resolves these inconsistencies by always requiring at least one HDR-DDR Data Word for all HDR-DDR transactions. Furthermore, Errata 01 clarifies the requirements for CCC flows in HDR-DDR Mode, and re-defines the special use of the structured protocol elements for these CCC flows to always include at least one HDR-DDR Data Word for appropriate acknowledgement.
2. Clarifying Open-Drain timing parameters
   The timing parameters for I3C v1.1 did not show appropriate definitions for a ‘Pure Bus’ configuration, and also did not provide clarity for sending the first I3C Address Header with the Broadcast Address (i.e., 7’h7E) in order to disable the I2C Spike Filter (for certain I3C Devices). Errata 01 clarifies these timing parameters and fixes other related incorrect timing parameter definitions.
3. Updating obsolete FSM Diagrams
   Several FSM diagrams in Annex C that were initially created during early stages of I3C v1.0 specification development were obsolete. For example, the FSM diagram for Dynamic Address Assignment did not reflect the correct Dynamic Address Assignment procedure, and did not include newer CCCs (such as the SETAASA CCC) that were added after I3C v1.0. Several other issues and inconsistencies were also found in other FSM diagrams in Annex C.
   Errata 01 updates these FSM diagrams to reflect the correct procedures (per the normative text in the I3C v1.1 specification) and to remove other obsolete terminology.
4. Typographical fix regarding HDR-TSP and Multi-Lane support
   Errata 01 corrects a minor typographical error, and resolves an inconsistency regarding which HDR Modes support Multi-Lane transfers in I3C v1.1.
   Additionally, these issues, plus numerous other inconsistencies, clarifications, and fixes have been addressed in MIPI I3C v1.1.1 [MIPI14]. MIPI Alliance strongly recommends that all implementers move to MIPI I3C v1.1.1 as the newest recommended version of the I3C specification.

Not at this time. However, the MIPI I3C WG meets regularly and is considering proposals to revise and extend I3C. As part of maintaining the I3C specification, the MIPI I3C WG seeks to improve the I3C specification in areas where it would benefit from clarification or additional explanation. Please direct any comments or suggestions to MIPI Alliance.

Yes, a number of companies have released products that feature integrated I3C Controller and I3C Target 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.

Some vendors have started to offer Target and/or Controller IP cores for integration into ASIC devices and FPGAs, including a free-of-cost Target IP available for prototyping and integration.

The maximum wire length would be a function of speed, as all the reflections and Bus turnaround must complete within one cycle. Larger distances can be achieved at the lower speeds than at the higher ones. For example, at 1 meter (between Controller and Target), the maximum effective speed is around 6 MHz for read, to allow for clock propagation time to Target and SDA return time to Controller.

No. The I3C CCCs are always preceded by the I3C Broadcast Address, 7’h7E. Since the I2C specification reserves address 7’h7E, no Legacy I2C Target will match the I3C Broadcast Address, and thus no Legacy I2C Target would respond to the I3C commands. Likewise, the Dynamic Addresses assigned to I3C Devices would not overlap the I2C static addresses, so no I2C device would respond to any I3C address – even if it could see it.

Unlike I²C, there is no natural way to hang the I3C Bus. In I²C, clock stretching (where the Target holds the clock low, stopping it from operating) often causes serious problems with no fix: there’s simply no way to get the Target’s attention if it has hung the Bus. By contrast, in I3C only the Controller drives the clock, and so the Target performs all actions on SDA relative to that clock, thereby eliminating the normal causes of such hangs.

Further, since I3C is designed to ensure that I3C Targets can operate their back-end I3C peripheral off the SCL clock (vs. oversampling), any problems elsewhere in the Target won’t translate into Bus hangs.

If a system implementer is highly concerned about a Target accidently locking itself, then a separate

hard-reset line could be used. Alternatively, the I3C v1.1.1 and I3C Basic v1.1.1 specifications add a new feature called Target Reset for resetting non-responsive I3C Targets: if an I3C Controller emits the Target Reset Pattern (a defined unique Bus pattern that does not otherwise occur during regular communication), then the Devices on the Bus will treat it just like a hardwired reset line.

This question has been updated for I3C v1.1.1 and I3C Basic v1.1.1.

There are three major outputs from a MIPI I3C Interoperability Workshop:

• Participating vendors can get detailed information about how well their I3C implementations interoperate with other vendors’ implementation. Vendors can also compare their results with one another.
• MIPI Alliance can generate an overall picture of the industry state-of-the-I3C-implementaion. For example, how many vendors have implemented I3C, and how many implementations pass or fail against one another.
• The MIPI I3C Working Group gets better understanding about any major issues with the I3C specification. The WG can then leverage that learning by adding to this FAQ, other supporting documents (such as Application Notes, per Q8.1), and possible future revision of MIPI I3C Specifications.

In general, any MIPI Alliance members who have I3C hardware ready to interop can participate.

Yes, MIPI Alliance has released a CTS for I3C v1.1.1 and I3C Basic v1.1.1 [MIPI09].

Interoperability Workshops will ultimately follow the tests identified in the I3C CTS, as and when such events can be arranged by MIPI Alliance.

The basic byte-based messaging schemes used in I²C and SPI map easily onto I3C. Additionally, a set of Common Command Codes (CCCs) has been defined for standard operations like enabling and disabling events, managing I3C-specific features (e.g., Dynamic Addressing, Timing Control), and other functions. CCCs are either Broadcasted (i.e., sent to all Devices on the I3C Bus), or else Directed to a particular Device on the I3C Bus (i.e., by Address).

CCCs do not interfere with, and do not consume any of the message space of, normal Controller-to-Target communications. That is, I3C provides a separate namespace for CCCs (see the specification at Section 5.1.9.3).

Yes, multi-Target I3C chips are possible. I3C v1.1 also defines Virtual Target capabilities; see Q20.2, "What is a Virtual Target?" for examples of Virtual Targets.

Yes, I3C allows for multiple Controllers on the same Bus. However, only one Controller can have control of the Bus (i.e., can possess the Controller Role) at any given time.

An I3C Bus has one Primary Controller that initially configures the Bus and acts as the initial Active

Controller. Optionally, the Bus can also have one or more Secondary Controller Devices; these initially act as Targets, but any one of them can send the Active Controller a Controller Role Request (CRR) to ask to take over the role of Active Controller. Once the Active Controller agrees to a CRR and transfers Bus control (i.e., transfers the Controller Role) to a requesting Secondary Controller Device, the requesting Device then becomes the new Active Controller.

Note: The previous Active Controller (including the Primary Controller) can attempt to regain Bus control by performing this same CRR process. Once the previous Active Controller passes the Controller Role to another Controller-capable Device, it typically acts as a Target (i.e., with limited scope) until it receives the Controller Role again. The terms Active Controller and Secondary Controller reflect the current role of the Device at any given time, not the Device’s initial configuration or capabilities. See the specification at Section 5.1.7 for more details.

If the Active Controller crashes or becomes unresponsive, then other Controller-capable Devices may use the optional Error Type DBR procedure to test the Bus and regain control if necessary. For details, see the specification at Section 5.1.10.1.8.

Note: This question was updated for I3C v1.1.1 and I3C Basic v1.1.1.

I3C Target Devices that have a Static Address can operate as I2C Targets on an I2C bus; optionally, they can also have a 50 ns spike filter.

Additional requirements also apply; see also Q15.4, "How does an I3C Target behave with an I2C Controller vs. with an I3C Controller?" and the specification at Section 5.1.1.1.

Normally, once an I3C Target is assigned an I3C Dynamic Address, it will be retained until the Target is de-powered. However, an I3C Target will lose its I3C Dynamic Address as a result of the RSTDAA Broadcast CCC, since this resets all I3C Targets back to their initial state. After RSTDAA, I3C Targets that can also operate on a Legacy   I2C Bus (per Q15.2, "Can I3C Devices operate on a Legacy I2C Bus?") would behave as I2C Targets, per the specification at  Section 5.1.2.1.1.

Note: The RSTDAA Broadcast CCC is not normally used; it would only be used to assign a new Dynamic Address, or to return I3C Targets to their initial state.

An I3C Target could also lose its Dynamic Address under other circumstances, for example:

• The Device is reset by an out-of-band method, such as a pin-reset
• The Device is reset by a full Target Reset (starting with I3C v1.1) which can be invoked two different ways:
  
  • RSTACT CCC with Defining Byte 0x02, followed by Target Reset Pattern (per the specification at Section 5.1.11.2)
  • Two consecutive Target Reset Patterns (per the specification at Section 5.1.11.1)
• The Device goes into deepest-sleep (i.e., power down)

In the case of an I3C Device losing its Dynamic Address in non-standard ways, the Hot-Join mechanism allows the Target to notify the Controller of the event and receive a new Dynamic Address. In cases where the Controller has deliberately caused the Target to lose its Dynamic Address (e.g., by sending the RSTDAA CCC, or by causing a Target reset), the I3C Controller will start a new Dynamic Address Assignment process using the ENTDAA, SETDASA, or SETAASA CCC.

Note: See also Q20.1, "What is Offline, and what does it mean to be Offline Capable?" for Offline Mode for I3C Targets, where the Devices retain their Dynamic Addresses through a power-down or deepest-sleep cycle.

The first part of the PID contains a unique Manufacturer ID. Companies need not be MIPI Alliance members to be assigned a unique Manufacturer ID.

The second part of the PID normally contains a part number (which is normally divided up into general and specific part info for that vendor), as well as possibly an instance number which allows for multiple instances of the same device on the same I3C Bus. The instance ID is usually fed from a pin-strap, fuse(s), or non- volatile memory (NVM).

A random number may be used for the part number, although normally only for test mode, as set by the Controller using the ENTTM (Enter Test Mode) CCC. When a Device that supports random values enters the test mode, the PID[31:0] bits are randomized. When the Controller exits the test mode, the Devices reset bits PID[31:0] to their default value.

Note: The use of a random number in the PID allows for many instances of the same Device to be attached to a gang programmer/tester, relying on the random number to uniquely give each a Dynamic Address. However, the random number should not be used for typical I3C applications where I3C Devices must be uniquely identified, especially by higher-level software that runs on the Application Host that is driving the I3C Controller.

All I3C Targets must be able to process Broadcast CCCs at any time, whether or not they have been assigned a Dynamic Address. I3C v1.1.1 and I3C Basic v1.1.1 clarify the I3C Target requirements (see the specifications at Section 5.1.2.1) and also clarify which CCCs are required to be supported (see Q18.7, "Which Dynamic Address Assignment CCCs is a Device required to support?") and the specifications at Section 5.1.9.3).

Example: An I3C Device may act as an I²C device before it receives its assigned Dynamic Address. However, the Device is still expected to ACK the START with the Broadcast Address (7’h7E). The only exception would be if the Device were to choose to remain an I²C-only device; in this case, the Device would leave any 50 ns spike filter enabled (see the specifications at Section 5.1.2.1).

Note: Devices that do recognize START with the Broadcast Address could see any CCC (not just ENTDAA, SETDASA, or SETAASA). When determining what effect each CCC will have, these Device may take into account whether or not the Device has received an assigned Dynamic Address. Forz, if the Device has not yet received its assigned Dynamic Address, then receipt of the RSTDAA CCC should probably have no effect.

I3C Controller Devices that comply with the MIPI I3C Host Controller Interface specification (i.e., I3C HCI  v1.0 [MIPI02] or v1.1 [MIPI13]) can easily support Pending Read Notifications. MIPI I3C HCI already defines a standard feature known as “Auto-Command” that conforms to the Pending Read Notification  contract and enables (in SDR Mode) automatic initiation of Private Reads or (in supported HDR Modes) Generic Reads in hardware, without software intervention, based on matching MDB values in IBIs received from I3C Target Devices.

Implementers of other I3C Controller Devices could choose to offer support for Pending Read Notifications as a feature in hardware and/or firmware, with varying degrees of configurability. In situations where hardware or firmware support is not feasible, an I3C Controller Device and its Host could also support this in software, provided that the Host’s software upholds all the expectations in the Pending Read Notification contract (see specification Section 5.1.6.2.2). Note that this may require the ability to pause or cancel any previously enqueued Read transfers if the I3C Controller receives such an IBI with matching MDB value to signal a Pending Read Notification, as this would oblige the I3C Controller or its Host to initiate a Read (i.e., SDR Private Read or HDR Generic Read) that is expected for this particular IBI.

Yes. An I3C Target is expected to monitor Broadcast CCCs; the special exception is for Hot-Join Targets, as explained below.

Under most circumstances the Target should process all supported Broadcast CCCs, however the Target is specifically required to process supported Broadcast CCCs that affect Bus state. This includes the ENTHDRn  CCCs (which turn the HDR Exit Detector on), as well as the ENEC and DISEC CCCs for whatever events the Target supports (e.g., IBI).

Note: As a practical matter, the I3C Primary Controller will not generally use any CCCs other than Dynamic Address assignment while bringing up the I3C Bus. However, it is allowed to use Bus state CCCs as  needed.

For a Hot-Join Target (i.e., a Target that needs to emit a Hot-Join Request to receive a Dynamic Address), this rule only applies once the Target is safely on the I3C Bus and eligible to emit a Hot-Join Request. Such a Target might also join the Bus without knowing the current state, so in order to know that a Broadcast CCC is being sent it needs to see a a period of inactivity followed by a valid START with the Broadcast Address. I3C v1.1.1 and I3C Basic v1.1.1 clarify these rules for Hot-Join eligibility; see also Q17.10, "What has changed regarding Hot-Join in I3C v1.1.1?" In such cases, a Target that has not yet seen a START and has also not become eligible to emit the Hot-Join Request might need to wait for a Bus Available Condition (per specification Section 5.1.3.2.2) before it can see a START; or a Bus Idle Condition (Section 5.1.3.2.3) before it would be eligible to pull SDA Low to initiate a START to emit its own Hot-Join Request (i.e., using the standard method).

So, as a general rule, the Target will emit the Hot-Join Request before the I3C Controller is able to emit any Broadcast CCCs. However, after that the Target may see one or more Broadcast CCCs prior to being assigned a Dynamic Address.

Only if they have a way to turn the Hot-Join feature off, or if passive Hot-Join is supported. (See Q17.7, "Can an I3C Target support Hot-Join when used on an I3C Bus, and still function correctly on a Legacy I2C Bus?")

Hot-Join Requests are not compatible with Legacy I2C controllers, so Hot-Join would have to be disabled for  the Target to be used on a Legacy I2C 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 I2C controller does not support the I3C protocol.

Yes, the reserved Hot-Join Address (7’h02) is safe even if multiple I3C Targets all simultaneously attempt to emit a Hot-Join Request. If multiple I3C Targets do join the I3C Bus and all become eligible to emit the Hot- Join Request (per specification Section 5.1.5) at the same time, then they would be expected (and allowed) to all emit the Hot-Join Request at the same time. Since a Hot-Join Request is a special form of the In-Band Interrupt Request with no data payload (i.e., no Mandatory Data Byte), multiple I3C Targets may all emit this request at the same time, provided that they are all eligible to do so.

Example: As one I3C Target pulls SDA Low to initiate the START Request and drive the 7’h02 Hot-Join Address into the Arbitrable Address Header, and the other eligible I3C Targets see this activity while they are eligible, they would also emit the same Hot-Join Address and behave accordingly. This could be useful if one  such I3C Target supported the standard Hot-Join method and waited for the Bus Available condition, while another such I3C Target only supported a passive Hot-Join method but was waiting for another I3C Device to initiate a START Request.

Upon receiving the Hot-Join Request and responding with ACK, the Controller sends the ENTDAA CCC (per specification Section 5.1.4.2) to signal its intent to start the Dynamic Address Assignment procedure and  assign Dynamic Addresses to all I3C Targets that have not yet received one. Since the Dynamic Address Assignment procedure inherently supports detection of multiple I3C Targets and uses Arbitration to select one I3C Target at a time (i.e., for each iteration of assignment), the Controller should continue the Dynamic Address Assignment procedure so it can catch all eligible I3C Targets that emitted the Hot-Join Request  together (as well as any that might have previously emitted the Hot-Join Request).

See Q17.10, "What has changed regarding Hot-Join in I3C v1.1.1?" for more information about Hot-Join Requests and the specification clarifications that are new for I3C v1.1.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 Controller is required to  retry once for the Directed GET CCCs if the Target NACKs the first try. 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).

In general, the ranges of command codes byte values that are defined for Vendor or Standards use in specification Table 16 in Section 5.1.9.3 (i.e., the main table that defines the I3C Common Command Codes) can be used by any implementer or any standards developing organization to define custom CCCs that extend I3C to accommodate new use cases. However, the definition of custom CCCs should be considered carefully because the practical issues of implementation might lead to situations where interoperability could be affected across multiple I3C Target Devices that interpret the same command code differently.

For example, different implementers or standards groups might define a custom CCC using the same command code value (i.e., CCC byte value) with (for a Direct GET CCC) different interpretations of the message format that their custom Target Device should return, or (for a Direct SET CCC) different expectations about how their custom Target Device should act; or different expectations about which Defining Bytes might be supported for this CCC, for their custom Target Device. For these conflicting definitions, interoperability issues would certainly arise if the Controller used this custom CCC on an I3C Bus that used custom Target Devices from multiple implementers, or custom Target Devices that conformed to different standards published by several such standards groups. The Controller would not necessarily have knowledge of this situation until it detected protocol issues or encountered other errors.

To help alleviate this situation, I3C v1.1 and I3C Basic v1.1.1 add a new SETBUSCON CCC (see specification Section 5.1.9.3.31) that allows the Controller to set the Bus context. This CCC informs Targets about which version of I3C is used on the Bus, and whether it is a standards-based Bus and/or a vendor-private Bus. This information allows the Target to coordinate its interpretation of extended CCCs, as well as other uses of the Bus, to match the actual current Bus context. Although the SETBUSCON feature is fully optional, it provides a powerful way to align standards-group-based uses of I3C with coordinated private uses. To foster proper coordination, SETBUSCON Context Byte values are published on the MIPI Alliance public website [MIPI11], and may be assigned by request.

MIPI Alliance strongly recommends that standards groups utilize the SETBUSCON CCC to prevent such interoperability issues, by requesting an assigned Context Byte for their particular usage, which might include a specific interpretation of any command codes that are defined for vendor or Standards use. Additionally, such custom Target Device implementations should not enable this custom interpretation by default, until they receive the SETBUSCON CCC with an assigned Context Byte from the I3C Controller.

MIPI Alliance offers a similar recommendation to implementers seeking to define custom CCCs for private use in a custom Target Device, by using similar logic in such a Target implementation to not enable this custom interpretation by default, until receiving the SETBUSCON CCC with a suitable Context Byte from the I3C Controller to explicitly enable a private interpretation.

In I3C v1.1.1 and I3C Basic v1.1.1, a new dummy command code value 0x1F is defined for special use only in CCC flows for HDR Modes that require special structured protocol elements (i.e., Words or Blocks) to conform to that HDR Mode’s coding. This 0x1F dummy command code has no meaning as a standard CCC. But in such special flows, it takes the place of a valid CCC and is used in a valid End-of-CCC Procedure to signal the end of CCC modality and return to that HDR Mode’s standard generic HDR Write and Read transfers. Dummy command code 0x1F is currently used solely in HDR-DDR Mode, where every HDR-DDR Write must include at least one HDR-DDR Data Word.

Note: In I3C v1.1, the equivalent End-of-CCC Procedure was incorrectly defined. Errata 01 for I3C v1.1 addresses this with an updated definition using this dummy command code. Implementers should use only the updated definition in Errata 01 (or newer), or in I3C v1.1.1 (or newer). See Q4.4, "Are there any impending fixes or errata for MIPI I3C v1.1 that should be applied now?".

Dummy command code 0x1F may not be used in SDR Mode, nor in any HDR Modes other than HDR-DDR Mode. Dummy command code 0x1F has no meaning as a standard CCC.

The RSTDAA CCC originally (i.e., In I3C v1.0 and I3C Basic v1.0) had a Direct CCC form which could be used to reset a Dynamic Address for a single I3C Target. The Direct CCC form of RSTDAA was deprecated In I3C v1.1 and I3C Basic v1.1.1 because it was realized that the RSTDAA CCC should not be directed to just one Target.

Note: A Controller that needs to reassign one Target’s address can use the SETNEWDA CCC, if the Target supports that CCC.

In I3C v1.1, specification Section 5.1.7.3 erroneously stated that this is the GETMXDS Format 2 CCC. In fact, it is Format 3, as stated in other sections. I3C v1.1.1 corrects this error and renames the Defining Byte to CRHDLY (i.e., Controller Role Handoff DeLaY).

In I3C v1.1.1 and I3C Basic v1.1.1, the DEFSLVS CCC has been renamed to DEFTGTS (DEFine list of TarGeTS) because the term ‘Slave’ has been deprecated per Q5.2, "What is an I3C “Target” Device, and why was the I3C “Slave” Device renamed?" Note that this is only a naming change; there is no technical change. In all other respects, DEFTGTS is identical to the former DEFSLVS, and is used in exactly the same manner.

Starting with I3C and I3C Basic v1.1.1, a number of terms used in earlier versions, including the names of some Defining Bytes, have been deprecated as detailed in Q5.1 ("What is an I3C “Controller” Device, and why was the I3C “Master” Device renamed?") and Q5.2, "What is an I3C “Target” Device, and why was the I3C “Slave” Device renamed?"). Note that these are only naming changes; there are no technical changes. In all other respects, these Defining Bytes are identical to the ones in earlier I3C specification versions, and are used in exactly the same manner.

Note: This question does not apply to I3C Basic.

In I3C v1.1.1, Defining Byte values 0x7F and 0x55 now describe the process of configuring and enabling Data Transfer Early Termination in addition to the previously described HDR Ternary Flow Control. In the I3C v1.1 specification this was defined as ACK/NACK only for WRITE Commands, whereas it actually applies to all HDR-Ternary Commands. The new definition of HDR Ternary Flow Control clarifies the full set of features that these Defining Bytes (as Sub-Commands) configure.

Additionally, specification Section 5.2.3.3 now provides more context for these capabilities, provides a better explanation of the default state of HDR Ternary Flow Control, and defines which of the procedures defined in its sub-sections apply when HDR Ternary Flow Control is enabled vs. is disabled.

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

No, there is an error in the I3C v1.0 specification’s Figure 52. The beginning of the Restart/Exit Pattern should show SCL Low and SDA changing. This error was corrected in the I3C v1.1 specification and subsequent versions.

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

Per Q21.3 ("When is the Pull-Up resistor enabled?") and Q21.4 ("Is a High-Keeper needed for the I3C Bus?"), the Controller manages its Pull-Ups to allow for ACK/NACK as well as Bus

Turnaround. The Controller sends the HDR-DDR Command Word with SDA in Active drive (i.e., Push-Pull mode) for the Command Word until the last Parity bit (i.e., PA0), which is initially driven High. Before the falling edge of C10 cycle, the Controller prepares for the Target to respond by disabling Push-Pull mode and engaging an appropriate Pull-Up to keep SDA at High. After the rising edge of the next C1 cycle, the addressed Target has the opportunity to either:

• Accept the DDR Write or Read by pulling SDA to Low, or
• Ignore the DDR Write or Read by leaving SDA at High

Note: This scheme is similar to SDR Mode’s ACK/NACK scheme for the Address Header, where SDA is “Parked” at High and the Target can pull SDA to Low to acknowledge the transaction.

The Controller should use the appropriate Pull-Up to enable Bus Turnaround or acceptance by the Target. For most use cases, the Open-Drain class Pull-Up is recommended; however, the High-Keeper could also be used, based on system design factors per specification Section 5.1.3.1. In either case, the Target must be able to pull SDA to Low before the falling edge of the C1 cycle.

Note that the next C1 cycle is the start of the first HDR-DDR Data Word (if the Target accepts the transfer) and the PRE1 bit (i.e., the rising edge of the C1 cycle) is always 1’b1 per Section 5.2.2. Using this scheme, the Target’s response determines the preamble bits:

• Bits 2’b10 indicate a Target ACK (i.e., accepting the DDR Write or Read) which starts the first HDR-DDR Data Word; or
• Bits 2’b11 indicate a Target NACK (i.e., ignoring the DDR Write or Read). The Controller then drives the HDR Restart Pattern or HDR Exit Pattern.

Note: This question does not apply to I3C Basic

In addition to the changes regarding ENDXFER and HDR Ternary Flow Control (see Q18.16, "What has changed with the ENDXFER CCC for HDR-TSP and HDR-TSL Modes?"), I3C v1.1.1 now includes:

• Clarifications on the use of Group Addresses for Direct CCC Read/Write segments in HDR Ternary Modes
• Configuration advisories regarding use of common HDR Ternary Flow Control with CCCs, especially when sending Direct CCCs to Group Addresses.
• Clarification to the Option 2 End of CCC Procedure, which is now similar to starting a new CCC: all I3C Targets must acknowledge the Write Command to the Broadcast Address before the Controller sends an HDR Restart Pattern to end the CCC modality and return to generic HDR Ternary Read/Write commands.

Yes. In the I3C v1.1 specification, Figure 164 CRC Block for Dual Lane and Quad Lane (i.e., the HDR-BT CRC Block) presented the Dual Lane encoding of the CRC Block inaccurately, specifically in the Transition_Verify byte:

• For HDR-BT Read transfers where the Target provides the clock, the figure incorrectly indicated the “handoff” point (where the Controller resumes driving SCL) as the C12 falling edge, i.e., the very end of the Transition_Verify byte for Dual Lane. The text of specification Section 5.2.4.2. and Section 5.2.4.3.3, by contrast, correctly defines the “handoff” point for Dual-Lane as the second half-clock of the Transition_Verify byte, i.e., the C11 falling edge.
• Figure 164 also incorrectly showed that the SDA[0] Lane could optionally be High after the “Park1, High-Z” on the C11\ clock cycle (i.e., Bits 4 and 6). The specification text, by contrast, correctly defines Bits[7:2] of the Transition_Verify byte as reserved, and requires them to be set to 0. In I3C v1.1.1, the specification text now defines Bits[4:2] as always 0, with Bits[7:5] still reserved for future definition by the MIPI I3C WG.

In both points above the v1.1 specification normative text was correct, and the Dual Lane HDR-BT CRC Block in Figure 164 was incorrect. The “handoff” point is indeed at the C11 falling edge, not the C12 falling edge. The I3C v1.1.1 specification clarifies these details and corrects the figure. Additionally, SDA[0] must be driven Low for Bit 4, even if the receiver does not drive SDA[0] Low and inform the transmitter that the CRC did not match after the “Park1, High-Z” (i.e., for the C11 falling edge).

Note: For a Read transfer where the Target was providing clock, the “handoff” is required to occur before the transmitter (i.e., the Target providing Read data) completes transmission of the Transition_Verify byte. In this case, the Target must then follow the Controller’s clock, since the Controller would drive SCL after the falling edge of C11.

Figure 2 shows a corrected version of the relevant details for the Dual Lane HDR-BT CRC Block, focusing on the Transition_Verify byte. The figure includes a portion of Figure 175 from the I3C v1.1.1 specification (see Section 5.2.4.6), highlighting the changes and clarifications.

Figure 2 Corrected Figure 164, CRC Block for Dual Lane

Note: The I3C v1.1.1 specification provides clarifications and improves the descriptions of the requirements for handling the Transition_Verify byte at the end of the CRC Block, for all defined Multi-Lane configurations, including cases where the receiver fails to acknowledge the transfer. In general, the Controller must control SDA[0] and any other SDA[1:3] data Lanes (per the Lane configuration) due to the updated definition of the bit fields in the Transition_Verify byte.

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

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

In a more advanced form, a Virtual Target 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 Targets.

For details, see the I3C v1.1 specification at Section 5.1.9.3.19, and the System Integrators Application Note for I3C [MIPI05] at Section 5.7.

In I3C v1.1, use of this CCC is expanded to support Bridging Devices that have Dynamic Addresses, which makes multiple Bridging Devices on the same I3C Bus possible. The context of the SETBRGTGT CCC is also redefined: a Bridging Device is now one of several types of Devices that expose or present Virtual Targets. Bit[4] of the Target’s Bus Configuration Register (BCR) now indicates Virtual Target capabilities.

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

For details, see the I3C v1.1 specification at Sections 5.1.1.2.1, 5.1.9.3.17, and 5.1.9.3.19.

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

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

Examples where Secondary Controllers are useful:

1. A Debug controller, if present, would be a Secondary Controller
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. For example, 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 Targets, as fully-fledged Primary Controllers, and as Secondary Controllers (i.e., Devices that come up as Targets but can become the Active Controller later), depending solely on the particular needs of the given system. They can simply be configured for the Bus they are on by the firmware.

Note: This FAQ entry has been updated for I3C v1.1.1 and I3C Basic v1.1.1. In this FAQ entry, the terms “Primary Controller” and “Secondary Controller” refer to an I3C Device’s initial configuration and capabilities. In other sections of this FAQ and the I3C specification, the term “Secondary Controller” might instead reflect a Controller-capable Device’s current role, i.e., as and when it is not currently the “Active Controller” of the Bus. See Q13.4 for additional details.

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.

Not necessarily. I3C Controllers manage an active (i.e., dynamic) Pull-Up resistance on SDA, which they can enable and disable as the Bus transitions between Open Drain and Push-Pull mode. This might be a board-level resistor that is switchable (i.e., that can be engaged/disengaged as needed, controlled by an output pin from the Controller), or internal to the Controller, or any combination of the two.

Note: If an I3C Bus has multiple Controller-capable Devices (i.e., one Active Controller and one or more Secondary Controllers), then the Active Controller manages the Pull-Up on SDA.

For normal active I3C Targets, yes. They should only send an In-Band Interrupt (IBI) Request when they have seen a STOP and the tAVAL time has elapsed (about 1 µs), and in response to a START (but not a Repeated START).

For Hot-Joining Devices using the standard Hot-Join method, they do not necessarily know the Bus condition, so they wait until the Bus is Idle (i.e., until SCL and SDA are both high for a duration of at least tIDLE).

Yes, the I3C Bus has elaborate error detection and recovery methods. Seven Target error types (TE0 through TE6) and four Controller error types (CE0 through CE3) are defined for SDR Mode, along with suggested recovery methods. In addition, a similar set of errors is defined for each HDR Mode.

Note: This question has been updated for I3C v1.1+ and I3C Basic v1.1.1. These versions add new Error Types CE3 and DBR.

Yes. An I3C Target may optionally watch for 60 µs with no SCL or SDA changes to make sure that the Bus is not in HDR Mode (and therefore must be in SDR Mode). After that, it is appropriate to wait for START (assumed to be Repeated START) or STOP.

The Protocol Error Report bit on the GETSTATUS CCC is intended to report errors that have no other way of being detected unless the Device reports them. It is intended to cover parity error, CRC error, and anything else that means that a message from the Controller was lost and the Controller has no way of knowing it.

The Protocol Error Report on the GETSTATUS CCC would not cover the case of TE5 errors, as they are more related to an unsupported CCC or Defining Byte (which is not a protocol error per se). It is also not intended for situations when the Target NACKs, because the Controller will know that an error occurred when the Target NACKs and recovers it. Errors such as Error Types TE0, TE3, TE4, and TE5 are detected by the Controller when the Target sends a NACK response, and are recovered by using the appropriate recovery methods; as a result, they need not be reported via the GETSTATUS CCC.

Error Types TE2 through TE5 should be recovered by STOP.

However:

• Error Types TE2, TE3, and TE5: Vendors may optionally elect to have Devices recover from these Error Types upon seeing a Repeated START, per the transaction type. For these Error Types that support optional Repeated START recovery, STOP is the second step of escalation after Repeated START recovery.
• Error Type TE4: Requires STOP recovery (the Repeated START option does not apply).

The RSTACT state will be cleared back to default upon either:

1. Detection of a Target Reset Pattern. This will enact the RSTACT action, and then clear the state.
2. Detection of a completed START (but not repeated START). The RSTACT may be cleared either on that falling edge, or on the rising edge that follows.

If the Target does not receive a RSTACT CCC before seeing the Target Reset Pattern, then it uses the default action of Peripheral Reset: it resets just the I3C block. If the Target again receives no RSTACT CCC before seeing a Target Reset, it then escalates to a Full/Chip Reset. It therefore retains the state after any default Peripheral Reset, so it can then activate the escalation. This state is cleared if the Target sees either an RSTACT CCC, or a GETSTATUS CCC addressed to it.

Note: The purpose of this mechanism is to fix a broken system or setup. Because the Target Reset Pattern Detector logic is normally separated both from the I3C block and from other parts of the main system, it will continue to work even if the rest of the chip becomes broken (e.g., clocks stopped, Bus locked up, etc.). This means that not seeing a RSTACT CCC would be a symptom of a large problem, so the Target escalates in order to recover from such a broken condition. The Target first performs a Peripheral Reset, in case the fault condition exists only in the I3C block itself.

In the I3C v1.1 specification, Table 110 I3C Open Draining Timing Parameters shows the tHigh symbol maximum value as 41 ns, and Note 4 states “tHigh may be exceeded when the signals can be safely seen by I2C Targets”. This means that a 41 ns tHigh will ensure that no Legacy I2C Target will see the SCL changes, and so no Legacy I2C Target will interpret the START followed by the Address phase nor the ACK/NACK. If there is no harm with a Legacy I2C Target on the I3C Bus seeing the clocks, then the Controller may use a much longer tHigh. For example, Legacy I2C Targets will see the STOP and then a START. It is acceptable for them to see the Address that follows (arbitrated or not), since none of those Addresses will match their own Address. However, as the tLow may well be 200 ns, this may present problems for any Legacy I2C Targets not fast enough to correctly handle a 200 ns Low period.

In the I3C v1.1.1 specification, the parameters are defined in the equivalent Table 122. In the I3C Basic v1.1.1 specification, the parameters are defined in the equivalent Table 86.

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

No. The tSCO (Clock-to-Data Turnaround delay time) parameter is information provided by Target Devices so that system designers can properly compute the maximum effective frequency for reads on the Bus. The tSCO number is meant to be used together with the line capacitance (trace length) and number of Targets and stubs (if present).

However, I3C Targets with tSCO delay greater than 12 ns must do all of the following:

• Set the Limitation bit in the Bus Characteristics Register (BCR) to 1’b1
• Set the Clock-to-Data Turnaround field of the maxRD Byte to 3’b111
• Communicate the tSCO value to the Controller by private agreement (i.e., product datasheet)

Note: I3C Basic v1.0 and I3C v1.1+ already clarify these aspects of communications in I3C.