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 alternately writing to, and then reading data from, one or more specific I3C Target Devices. The Direct Write/Read Command uses the Direct CCC framing model per specification Section
    Example: An I3C Controller might use the MLANE CCC (Section to configure an I3C Target 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, Target_Addr, ....
      For more framing details for SDR Mode, see Table 15 in Section
    2. In CCC framing for HDR Modes, the Defining Byte is sent in the HDR-x CCC Header Block 946 of type Indicator. This framing element is defined differently for each HDR Mode; for more 947 framing details, see Table 53 in Section
      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-Target 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 Target Device, as a Direct GET CCC; another sub-command might be used to either configure an I3C Target 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 selects among several different capabilities areas, to read from an I3C Target 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 Target Device.
    For some new Direct CCCs defined in I3C v1.1, a Defining Byte is required.

    1. New Optional Defining Bytes: In I3C v1.1, some CCCs that in I3C v1.0 had no Defining Byte now do have optional Defining Bytes to extend their functionality and support other new behaviors. If the I3C Controller 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

      Many Direct GET CCCs that allow optional Defining Bytes also have a method for indicating 970  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 Controller to query an I3C Target 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 at Section Additionally, for I3C  Target 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.

    Note: 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 Controller can use the GETSTATUS CCC (see Section to determine the operational status of an I3C Target Device. All I3C Targets support the use of GETSTATUS without a Defining Byte. But if an I3C Target also supports the GETSTATUS CCC with any optional Defining Bytes, then the I3C Controller 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 Target 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 Target Status). For example, if a Defining Byte value of 0x91 (“SECMST”) is supported, then using this Defining Byte would request the Target to return alternate status information related to the Target’s Secondary Controller capabilities.
FAQ Type: