At 4 bytes counting command, data, and PEC, if any, the 4 byte RXBUF will be full. The RXBUF must be read, and the ACK bit set, before the PMBus hardware can accept more data. If the firmware is quick enough, there will be no clock stretching. The PMBus hardware automatically provides clock stretching on the ACK for the 4th byte, if it is necessary. Here is the timing diagram:

Figure 10-6 Timing Diagram

1. RXBUF is full, number of bytes received is equivalent to RX_BYTE_ACK_CNT. DATA_RDY is set and RD_BYTE_COUNT is loaded with a 4. The interface is prepared to stretch the clock. This occurs t_DRDY after the falling edge of the clock for bit 8.
2. The firmware reads the data from RXBUF and writes a 1 to the ACK bit. This turns off the clock stretch. The delay between write to ACK and disable of clock stretch is t_ACKWRITE. Reading from PMBST clears the DATA_RDY bit and the RD_BYTE_COUNT bits.
3. On the falling edge of PMBUS_CLK indicating the STOP signal, the EOM bit is set, and the PEC_VALID bit is set or cleared to indicate if the last byte was a valid PEC. The timing after the falling edge is tEOM.

If step 3 is delayed, clock stretching of the next valid address will occur in the same way as described in Section 10.4.1.

The exact same sequence will occur if the 3rd data byte is replaced with a valid PEC, except that the PEC_VALID bit will be always set.

For messages with 5 through 7 bytes, the sequence will be as described below:

Figure 10-7 Write 4 Bytes + Command

There are 4 items here:

1. DATA_RDY and RD_BYTE_COUNT set as described above
2. DATA_RDY and RD_BYTE_COUNT cleared by read from PMBST, data read from RXBUF, 1 written to ACK bit. Clock stretch released.
3. ACK bit cleared by occurrence of ACK on bus.
4. Here the EOM and DATA_RDY bit are set, and the RD_BYTE_COUNT and PEC_VALID bits are loaded with appropriate values. RD_BYTE_COUNT will be loaded with a 1, showing that there is one byte in the RXBUF. After this, the sequence is the same as described in Section 10.4.1.

Writing 6 and 7 total bytes will have the same effect, except that there will be a different number in the RD_BYTE_COUNT register. At 8 bytes, the sequence at the end of the message will be the same as at 4 bytes, because RXBUF will be full again. At 9 bytes, the end of the message will be the same as at 5. And it will continue the same after that. If the RXBUF is not full when the STOP occurs, all 4 bitfields will be loaded simultaneously. If the last byte fills up RXBUF, the data must be acknowledged by writing to ACK before the clock stretch will be released.