How is the GETMXDS CCC (maximum data speed) updated in I3C v1.1?

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

How do tCBSr and tCASr timing differ between I3C v1.1 and I3C v1.0?

In I3C v1.1, tCASr’s minimum value is reduced to tCASmin/2 (whereas in I3C v1.0, it is tCASmin). This reduced duration might be a challenge for some Slaves. In order to prevent such situations, the Master of the Bus shall provide suitable timing, accommodating the slowest Devices on the Bus.

In the I3C v1.1 Specification, Table 111 “I3C Push-Pull Timing Parameters for SDR, ML, HDR-DDR, and HDR-BT Modes” includes a clarifying note:

How does the Set Bridge Targets (SETBRGTGT) CCC differ between I3C v1.0 and I3C v1.1?

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

What happens if the Master crashes during a Read?

The I3C Slave should time out if it experiences more than 100 µs with no SCL, and abandon the read. It does not have to be precise, but since I3C’s minimum frequency is 10 KHz, anything longer than 100  µs means that the Master has failed to complete the Read, so the Slave should High-Z the SDA and abandon the Read.

Note that if the Slave is in legacy I2C mode, then it would not normally abandon the read, since there is no minimum frequency, and because 9 clocks by a Master will be enough to abort the Read (since the 9th bit of data is ACK/NACK).