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.
FAQ Type: 
I3C