At Section 22.214.171.124.3 the I3C v1.1 Specification states: “I3C mandates a single-retry model for Direct GET CCC Commands.” Based on this statement, adopters have a general notion that the Master is required to retry once for the Directed GET CCCs if the Slave NACKs for the first time. This may not be applicable for other “read” Directed CCCs (such as RSTACT, MLANE, vendor read, etc.) that are not defined for dedicated Read CCCs (i.e., CCCs that have names of the form GETxxx).
Please see the I3C v1.1 Specification at Section 126.96.36.199.
Does an I3C Slave need to receive and process the Broadcast ENEC, DISEC, and other Bus-state CCCs before being assigned a Dynamic Address?
Yes. An I3C Slave is expected to monitor Broadcast CCCs; the special exception is for Hot-Join Slaves, as explained below.
The Slave should process all supported Broadcast CCCs, but it is required to process supported ones 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 Slave supports (e.g., IBI).
This topic is extensively explained in the I3C v1.1 Specification at Section 188.8.131.52.18.
In I3C v1.1, Table 10 (I3C Open Draining Timing parameters) lists the tHigh symbol as having a maximum value of 41 ns, and then Note 4 says that “tHigh may be exceeded when the signals can be safely seen by I2C Slaves”. This means that a 41 ns tHigh will ensure that no legacy I2C Slave will see the SCL changes, and so will not interpret the START followed by the Address phase nor the ACK/NACK. The Master may use a much longer tHigh if there is no harm with a legacy I2C Slave on the I3C Bus seeing the clocks.
Yes. The I3C Master must emit the first START, 7’h7E at Open-Drain speeds (usually I2C Fm+ speeds) so that I3C Slaves with I2C Spike Filters will be able to see the I3C Broadcast Address, and then as a result turn off the Spike Filter. If the Master knows that none of the I3C Slaves has a Spike Filter, then it may omit this. Similarly, if the Master knows that all of the I3C Slaves have accurate Spike Filters, then it may use the I3C 2.5 MHz open-drain speed (i.e., 200 ns Low, 200 ns High).
If the Slave does not receieve a RSTACT CCC before seeing the Slave Reset Pattern, then it uses the default action of Peripheral Reset (i.e., reset just the I3C block). If the Slave again receives no RSTACT CCC before seeing a Slave Reset, then it then escalates to a Full-Chip Reset. It therefore holds the state after any default Peripheral Reset, so as to activate the escalation. That state is cleared if the Slave sees either an RSTACT CCC, or a GETSTATUS CCC addressed to it.
Although MIPI Alliance strongly recommends true support of Slave Reset, such that a Master can fully reset a Slave chip when needed, it is not required. Full Chip Reset allows replacement of the SRSTn trace that would normally be used to reset a Device.
The minimal reset is a reset of the I3C peripheral, at least to a level that will allow a ‘stuck’ I3C peripheral to start working again. How much of a reset that requires is up to the Slave Vendor; for example, it could be handled by an internal interrupt which would allow firmware/software in the Slave to handle the reset.
The RSTACT state will be cleared back to default upon either:
- Detection of a Slave Reset Pattern. This will enact the RSTACT action, and then clear the state.
- Detection of a completed START (but not repeated START). This consists of the SDA line going from High to Low while the SCL line remains High, followed by the first falling edge on SCL. The RSTACT may be cleared either on that falling edge, or on the rising edge that follows.
These errors should be recovered by STOP. But vendors can choose to recover from these errors when seeing a Repeated START. Note that STOP is the second step of escalation after Repeated START recovery.