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.

FAQ Type: 
I3C