Frequently Asked Questions

The parties that directly developed the MIPI I3C Basic specification have agreed to license all implementers on royalty free terms, as further described in the I3C Basic specification document [MIPI10][MIPI15]. Further, all implementers of the I3C Basic specification must commit to grant a reciprocal royalty free license to all other implementers if they wish to benefit from these royalty free license commitments. And, of course, MIPI itself does not charge royalties in connection with its specifications. MIPI’s intent is to create a robust royalty free environment for all implementers of I3C Basic.

No set of IPR terms can comprehensively address all potential risks, however. The terms apply only to those parties that agree to them, for example, and the scope of application is limited to what is described in the terms. Implementers must ultimately make their own risk assessment.

Yes, I3C Targets can initiate communication using In-Band Interrupt requests. Communication conflicts are solved by Target Address Arbitration.

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).

CCCs are the commands that an I3C Controller uses to communicate to some or all of the Targets 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 Target. 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 to specific Devices on the I3C Bus (i.e., by Address). All CCC command number values are allocated by MIPI Alliance, and some values are reserved for specific purposes including MIPI Alliance enhancements and other extensions (see Q18.4, "What are Vendor / Standard Extension CCCs, who can use them, and how are they differentiated among different uses?").

All three are special, in-band methods that allow the Target to notify the Controller of a new request or state, without having to wait for the Controller to query or poll the Target(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): A Target uses an IBI Request to notify the Controller of a new state or event. If the Target so indicates in the BCR, then an IBI may include one or more following data bytes. A Target can only use IBI if it has indicated the intent to do in its BCR.
  If the Target 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 Controller and Target.
• Hot-Join (HJ): A Hot-Join Request is used only by an I3C Target that hasn’t yet been assigned a Dynamic Address and is attached or awakened on the I3C Bus after the Primary Controller has initialized it. The Hot-Join Request uses a fixed address which is reserved for this purpose only. The Controller will recognize this fixed address and then initiate a new Dynamic Address Assignment procedure. However, a Target cannot use the Hot-Join Request before verifying that the I3C Bus is in SDR Mode.
• Controller Role Request (CRR): A Secondary Controller (including the Primary Controller, once it has given up the Controller Role) sends a CRR when it wants to become Controller of the I3C Bus. If the Active Controller accepts the CRR, then it will issue a GETACCCR CCC to pass the Controller Role to the requesting Secondary Controller. It is also possible for the Active Controller to initiate handoff on its own without any Target initiating an CRR, for example when a Secondary Controller wants to return control.

No. If an I3C Target will only be used on I3C Buses that rely on the SETAASA CCC (a Broadcast CCC that auto-sets the Target’s Dynamic Address from its I2C Static Address) and/or the SETDASA CCC (a Direct CCC where the Controller sets the Target’s Dynamic Address using a Direct CCC that references the Target’s I2C Static Address), then that Target will never be asked to use the ENTDAA CCC. In such a case, the I3C Target could participate on the I3C Bus despite not implementing ENTDAA CCC support. Since both of these CCCs rely on the Controller knowing that Target’s I2C Static Address (and perhaps the Static Addresses of all other Targets as well), these methods can save time for certain use cases, although they do impose some implementation requirements on the system designer.

Nonetheless, MIPI Alliance strongly recommends supporting the ENTDAA CCC, otherwise the Device will only ever be usable on that narrow subset of I3C Buses.

I3C supports Legacy I2C Target devices using Fast-mode (Fm, 400 KHz) and FastMode+ (Fm+, 1 MHz) with the 50 ns spike filter, but not the other I2C modes, and not I2C devices lacking the spike filter, or I2C devices that stretch the clock.

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.

During Bus initialization, the I3C Controller assigns a 7-bit Dynamic Address to each Device on the I3C Bus. For this to happen, each Target device must have a 48-bit Provisioned ID (that is, each Target is provisioned with its ID). The Provisioned ID has multiple fields, including MIPI Manufacturer ID and a vendor-defined part number. The I3C Target may also have a Static Address; if the Controller knows the Static Address, it allows for faster assignment of the Dynamic Address.

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.

With most configurations this is not possible, because each Device will have its own Manufacturer ID and a unique part number; as a result, no collisions are possible. But if more than one instance of the same Device (product) is used on a given I3C Bus, then each such instance must have a separate instance ID; otherwise there would be a collision. Likewise, if any Device is using a random number for its part number (i.e., in the PID), then multiple instances from that manufacturer could collide (i.e., could have the same random value that time).

If the Controller knows the number of Devices on the I3C Bus, then it can detect this condition: the number of Dynamic Addresses assigned would be less than the expected number of Devices. If that is detected, then the I3C Controller can take steps to resolve such collisions, for example by resetting all Dynamic Addresses with the RSTDAA CCC and restarting the process, or by declaring a system error after a set maximum number (e.g., 3) of such attempts fail.

Typically, an I3C Device that supports Group Addressing can be assigned to one or more Group Addresses, but has the same I3C Target configuration and state as any other I3C Target (i.e., its role does not change). In  effect, this Device gains the ability to receive I3C transfers that are addressed (i.e., targeted) to the Group Addresses to which it might be currently assigned, but the same configuration or state applies to the entire Target, equally for its assigned Dynamic Address as well as any and all assigned Group Addresses.

For some configuration changes, the I3C Controller may use certain Direct CCCs to configure an I3C Target,  either individually (i.e., by sending the Direct Write or Direct SET CCC to its Dynamic Address) or in a multicast manner (i.e., by sending the Direct SET CCC to the assigned Group Address). When used as a multicast, the Direct CCC is received by all I3C Targets that are assigned to that Group, and all such I3C Targets apply the same configuration change (if that CCC is supported), exactly as though each I3C Target had received the same Direct CCC addressed to its Dynamic Address. No other internal state is required, and no difference in behavior is expected, when such Direct CCCs are sent to a commonly-assigned Group Address vs. each individual Dynamic Address (see the specification at Section 5.1.9.4).

For other configuration changes, specifically for Multi-Lane configuration changes (if the I3C Target supports Multi-Lane transfers and separate Group Address configurations for Multi-Lane transfers, as defined in specification Section 5.3.1.1.1), a Direct CCC sent to a Group Address is a special configuration operation,  and the I3C Target must store this configuration differently than it would for the equivalent Direct CCC sent to its Dynamic Address. The MLANE CCC is a special case requiring different handling, where the Group Address must be treated specially (i.e., differently than the MLANE CCC sent to a Dynamic Address).

Other Direct CCCs are defined in a different way, and the I3C Target must treat Group Addresses specially.  Certain Direct CCCs should never be sent to a Group Address (see the specification at Section 5.1.2.1.3 and Section 5.1.9.4.)

Note: Section 5.1.4.4 in v1.1 of the I3C specification has a technical inaccuracy when it states that the SETGRPA CCC “assigns and unassigns a Group Address” to I3C Devices. In fact, the SETGRPA CCC only assigns a Group Address, it does not unassign a Group Address. This misstatement has been corrected in v1.1.1 of the I3C specification.

While the definition of In-Band Interrupts has not changed in I3C v1.1.1, some of the details of the Pending Read Notification contract (see specification Section 5.1.6.2.2) have been clarified. An I3C Target Device may only queue one active Pending Read Notification (i.e., a single message that will be read with either an SDR Private Read, or an HDR Generic Read) at a time; and it may now send another IBI if the I3C Controller  has not followed up to read the enqueued data for the Pending Read Notification:

• This IBI may be a reminder, using the same Mandatory Data Byte value that was sent earlier (i.e., it cannot be another MDB value that is also used for Pending Read Notifications).
  
  • If so, then it is forbidden to use it to indicate that additional Pending Read Notifications are waiting (i.e., that they are active and are enqueued after this notification), and the Controller is not obligated to keep count of these IBIs.
• Alternatively, this IBI may also indicate an error code or some other condition (i.e., due to delayed read).
  
  • However, the I3C Target must still keep the data available to read, if it can.

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.

The I3C Bus protocol supports a mechanism for Targets 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 Target can do this, e.g., a Target must wait for a Bus Idle condition.

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.

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

In I3C v1.0, an I3C Target was required to wait 1 ms (i.e., the tIDLE minimum value) before it could send a Hot-Join Request. Newer versions of the I3C specification define a new tIDLE 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 tIDLE minimum value of 200 µs.

Note: The new tIDLE minimum value of 200 µs is safe, as SCL at High in HDR Mode cannot exceed 100 µs (i.e., assuming a typical duty cycle) since the minimum I3C Bus frequency being 10 KHz.

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, but only if it supports the passive Hot-Join method defined in specification Section 5.1.5.3. If the Target does not support passive Hot-Join, then see Q17.6, "Can I3C Hot-Join Target Devices be used on a Legacy I2C bus?"

Before initiating the Hot-Join Request, a Target that supports passive Hot-Join must first ensure that it is actually on an I3C Bus. This can be done by waiting for a recognizable end of an SDR Frame that ends with  a STOP. The key difference is that in order to determine that this is actually an I3C Bus, the Target must first  see an SDR Frame addressed to the Broadcast Address (7’h7E / W). Following this, the Target could either pull SDA Low to drive a START condition, or wait to see a START that another I3C Device initiates, before emitting the Hot-Join Request (i.e., arbitrating the special Hot-Join Address 7’h02 into the Arbitrable Address Header following the START).

Note: A passive Hot-Joining Target needs to see an SDR Frame that is addressed to the Broadcast Address  in order to determine that the Bus is in SDR Mode. Without this knowledge, such a Target might see  Bus activity in HDR Modes and misinterpret it as STARTs and STOPs. Alternatively, a passive  Hot-Joining Target could wait for the HDR Exit Pattern because it clearly indicates a return to SDR Mode.

The detection of an SDR Frame that is addressed to the Broadcast Address is critical because a passive Hot-Joining Target might not engage its timer or oscillator (i.e., to check for Bus Idle or Bus Available condition) until it determines that it is on an I3C Bus and that the Bus is in SDR Mode. Without this detection, such a Target will not know whether it is safe to emit the Hot-Join Request.

If the Target ensures that it is indeed on an I3C Bus in this manner, then it must observe the standard behaviors of an I3C Target that has not yet received a Dynamic Address, as defined in specification Section 5.1.2.1. The Target must acknowledge the Broadcast Address (7’h7E), which means that it is required to understand and process all required CCCs, including ENEC and DISEC. Such a Target is not eligible to respond to the ENTDAA CCC before it has emitted the Hot-Join Request at least once.

A Target that supports both standard and passive Hot-Join methods is free to either A) Initiate a START, wait for the appropriate time (i.e., Bus Idle condition), emit the Hot-Join Request, and then pull SDA Low like a standard Hot-Joining Device; or B) Wait for a START that another I3C Device emits (i.e., after waiting for Bus Idle condition).

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.

After the NACK is preferred, but after the ACK is also acceptable.

The Hot-Join mechanism allows the Controller to first NACK, and then send the DISEC CCC with the DISHJ  bit set to disable subsequent Hot-Join Requests. If the Controller ACKs the Hot-Join Request, then that is interpreted as a promise that the Controller will eventually send the ENTDAA CCC to assign a Dynamic Address to the Target(s) that emitted the Hot-Join Request.

If the Controller were to send a subsequent DISEC CCC with the DISHJ bit set, then that would cancel this promise, but it would also leave the Target(s) with no Dynamic Address.

Note: If any additional Targets joined the Bus after the DISEC CCC was sent, then they would not have seen the DISEC CCC, and as a result would likely send their own Hot-Join Requests.

See Q17.10, "What has changed regarding Hot-Join in I3C v1.1.1?" for additional clarifications and updates in I3C v1.1.1 and I3C Basic v1.1.1.

In the I3C v1.0, I3C Basic v1.0, and I3C v1.1 specifications, the requirements for Hot-Join were not clearly defined and the Annex C Hot-Join FSM diagram did not illustrate all of the possible intended flows.

The I3C WG received implementer feedback on these points, and in I3C v1.1.1 clarified the normative requirements for a Hot-Joining Device. The WG also added a new definition of the Hot-Join procedure which  is now defined separately from the Target requirements. In addition, the Annex C Hot-Join FSM diagram now informatively illustrates a typical flow, rather than being presented as a representation of all possible Hot-Join Request flows.

To summarize the Hot-Join changes:

• A Hot-Joining Device that has not yet raised the Hot-Join Request (i.e., an In-Band Interrupt to the Reserved I3C Address of 7’h02 with Write) does not follow the standard behaviors of an I3C Target that has not yet received a Dynamic Address (as defined in specification Section 5.1.2.1) with the following exceptions:
  
  • If the Target supports a passive Hot-Join method (specification Section 5.1.5.3) and will be using that method instead of the standard Hot-Join Request (which usually requires the I3C Bus to go idle long enough to satisfy the Bus Idle Condition), then it must verify that the bus it is on is on an I3C Bus by watching for an SDR Frame. This means that the Target must already wait for a START with the 7’h7E Address. Q17.7, "Can an I3C Target support Hot-Join when used on an I3C Bus, and still function correctly on a Legacy I2C Bus?" provides more clarity on Targets that support passive Hot-Join.
• The Controller may choose to either ACK or NACK the Hot-Join Request, and may then send the ENTDAA CCC afterwards:
  
  • This may happen either immediately (i.e., after the next Repeated START), or later (i.e., after a prolonged period). The ENTDAA CCC might not be in the same SDR Frame, since the Controller may choose to send this after a STOP, followed by a delay (i.e., Bus Free Condition or longer) and then a START. Optionally, the Controller may initiate other transfers and/or CCCs between the ACK/NACK and the ENTDAA CCC.
  • In short, any valid actions are allowed between the ACK/NACK and ENTDAA CCC, and the Target should still respond to the ENTDAA CCC appropriately. If the Target knows that it needs a Dynamic Address and it has already raised the Hot-Join Request, then it should be ready to respond to the ENTDAA CCC when the Controller starts the Dynamic Address Assignment procedure.
  • If the Controller provided an ACK to the Hot-Join Request, then any Targets that raised the Hot-Join Request must remember that an ACK was provided, cease raising Hot-Join Requests, and remain ready to participate in a subsequent ENTDAA CCC (which the Controller should send at a later time). The Target should not send a subsequent Hot-Join Request if the Controller is slow to start the ENTDAA procedure.
  • Although providing an ACK for a Hot-Join Request is a typical flow, providing a NACK is also acceptable. The Target should remain ready to respond to the ENTDAA CCC in either case, even if the Target receives a NACK or is told by the Controller to stop sending Hot-Join Requests (i.e., using the DISEC CCC with the DISHJ bit set).
  • Note that the Controller may choose to send the DISEC CCC with the DISHJ bit set, after either providing an ACK or a NACK to a Hot-Join Request (see Q17.9).
• Any Targets that have already raised a Hot-Join Request are required to also respond to other required CCCs, per specification Section 5.1.2.1 which defines the standard behaviors for an I3C Target that has not yet received a Dynamic Address:
  
  • Such Targets must acknowledge the Broadcast Address (7’h7E). This means they are required to understand and process all required CCCs, including ENEC and DISEC. (Targets that support passive Hot-Join methods are already required to do this, once they successfully determine that they are indeed on an I3C Bus; 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?").
  • After either providing ACK or NACK in response to the Hot-Join Request, the Controller may send (and such Targets are required to properly receive) the DISEC CCC with the DISHJ bit set. The Controller doing so is required to prevent any Targets that raised a Hot-Join Request and received a NACK from subsequently attempting to raise a Hot-Join Request.
  • Subsequently, the Controller may send (and such Targets are required to properly receive) the ENEC CCC with the ENHJ bit set, to effectively re-enable Hot-Join Requests on the I3C Bus. Any eligible Targets that receive this ENEC CCC and that previously received the DISEC CCC with the DISHJ bit set may choose to re-send the Hot-Join Request if these Targets both (1) are capable of doing so, and (2) had originally emitted a Hot-Join Request, and (3) have not yet received a Dynamic Address.
  • If the Active Controller is a Secondary Controller Device that is not capable of processing Hot-Join or Dynamic Address Assignment, or one that wishes to defer processing to a more capable Controller (i.e., to the Primary Controller), then it may choose to disable Hot-Join on the I3C Bus by sending the DISEC CCC with the DISHJ bit set. It may then pass the Controller Role to any other Controller-capable Device, including but not limited to the Primary Controller.

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

Only for Data. The Data bytes are sent the same way as in SDR Mode. Figure 1 shows how Data is transferred from memory to the I3C Data Line.

Figure 1 Data DWORDs sent as SDR Data Bytes and HDR-DDR Data Words

The Command and CRC Byte are each transferred as a packet instead:

Command (MSb to LSb):

• Preamble (2 bits)
• Command (8 bits)
• Target address (7 bits)
• Reserved bit (1 bit)

CRC (MSb to LSb):

• Preamble (2 bits)
• Token (4 bits)
• CRC Byte (5 bits)
• Setup bits (2 bits)

Note: I3C Basic v1.1.1 and I3C v1.1+ already clarify the HDR-DDR protocol and coding details.

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.

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

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 I3C v1.1 and earlier, the flow for transitioning from ENTHDRx CCCs into HDR Modes was not fully defined. I3C v1.1.1 fully defines the flow for transitioning from such CCCs into the first transfer in an HDR Mode, as well as the corresponding flow transitions from the HDR Restart Pattern to the next HDR transfer in the same HDR Mode.

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.

In addition to the Multi-Lane changes for HDR-BT Mode (see Q18.17, "What has changed with the MLANE CCC and Multi-Lane Device configuration?"), specification Section 5.2.4 now adds:

• Definitions on how to compute the Parity bits in the HDR-BT Header Block
• Definitions and examples for the CRC-16 and CRC-32 polynomials as used for HDR-BT CRC Block checksums
• Clarifications on how the HDR-BT CRC checksum values are calculated based on the data for each HDR-BT transfer
• Correction of an error in the figure showing Direct CCC flows in HDR-BT Mode
• Clarifications on the use of Group Addresses for Direct CCC Read/Write segments in HDR-BT Mode
• Correction of a specification error concerning the use of HDR-BT CRC Blocks in CCC Flows in HDR-BT Mode
• Clarifications to the Transition_Verify byte in the HDR-BT CRC Block; Bits[4:2] are now redefined as always zero
• Added new figures in specification Section 5.2.4.6 showing the Single-Lane format for all HDR BT Mode structured protocol elements
• Corrections to the Dual-Lane and Quad-Lane figures for the HDR-BT Mode structured protocol elements, to resolve inconsistencies with the normative text and to show proper SDA Lane bit packing (i.e., the Transition, Transition_Control and Transition_Verify bytes)
• Detailed explanation of the Data Block Delay mechanism (formerly called the Stall [delay] mechanism), which allows an I3C Target to delay sending the next HDR-BT Data Block until it has collected enough data bytes (see Q19.9, "What is the HDR-BT Data Block Delay mechanism?")
• Better explanations of HDR-BT flow control details, including a new Section 5.2.4.7 with example HDR-BT transfers with different actions at the flow control points (i.e., the various Transition bytes)

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.

This mechanism allows an I3C Target to delay sending a complete HDR-BT Data Block during an HDR-BT Read transfer, for situations where the I3C Target or its inner system was unable to fully prepare enough data bytes to fill a Data Block as part of the Read transfer in HDR-BT Mode.

In I3C v1.1, the HDR-BT Data Block Delay mechanism was called the “Stall (delay) mechanism” and was not fully defined. Additionally, the name “Stall (delay)” was too easily confused with other I3C defined behaviors in which SCL clock stalling is permitted (i.e., stalling by the I3C Controller is allowed, but never stalling by an I3C Target). The confusion occurred because this HDR-BT mechanism is fundamentally different from SDR Mode SCL clock stalling, and I3C forbids SCL clock stalling in HDR-BT Mode

The I3C v1.1.1 specification addresses this confusion by renaming the mechanism to more accurately reflect its definition, and by adding clearer, more complete normative details. In addition, the name of parameter “tBT_STALL” was changed to “tBT_DBD”.

During an HDR-BT Read transfer, the Data Block Delay mechanism allows the I3C Target to transmit either:

• A valid Data Block, which is not intended to be the last such Data Block, if the Target has a full 32 bytes of data to transmit; or
• A single Delay byte, indicating that the Target is not yet ready to transmit a Data Block and that the I3C Controller should therefore continue the Read if it wishes to receive more data.

This Delay byte differs from a valid Transition_Control byte (i.e., the first byte of an HDR-BT Data Block). The I3C Target may defer sending a Data Block (i.e., by sending a Delay byte up to a maximum of 1024 times) at any point of a Read transfer, before it must terminate the Read transfer. The I3C Controller also has the opportunity either to continue waiting (i.e., receiving more Delay bytes until the I3C Target has enough data), or to terminate the Read transfer at its discretion.

This mechanism does not allow an I3C Target to delay sending either the CRC Block or the Last Data Block (e.g., one that might have “ragged” data).

The I3C Controller determines whether the I3C Target may use the Data Byte Delay mechanism. The Controller indicates this in the Control byte of the HDR-BT Header Block that starts each HDR-BT Read transfer.

• If the I3C Target supports this mechanism and chooses to use it for this transfer, then the Target may use the mechanism if needed.
• If the I3C Target does not support this mechanism, or if the I3C Controller has indicated that the Data Byte Delay is not permitted, then the I3C Target must not use this mechanism, in case it encountered a situation where it was unable to fully prepare enough bytes to fill a Data Block. In such a situation, the I3C Target might be forced to end the HDR-BT Read transfer early (i.e., by sending incomplete data).

This mechanism is primarily useful when the I3C Controller controls the SCL clock during the HDR-BT Read transfer, as the I3C Target would otherwise not have a method for indicating that the transfer should be slowed to match the actual rate of Data Blocks that it can reasonably produce (i.e., from its inner system that might provide the data bytes).