Vendor Specific Write CCCs

The Vendor Specific Write CCCs use the same Controller write transfer flow. The Target accepts both 'Vendor Specific Broadcast Write CCCs' and 'Address Matched Vendor Specific Directed Write CCCs' and passes them to the application through the Receive Buffer (Rx-FIFO) and indicates the control information of the Vendor Specific write CCC in the response passed through the Response Queue (I3CxRESPQUE).

The Target accepts the write address (ACK response) when all the following conditions are met:

• The Receive Buffer has space (in terms of empty locations) equal to or more than the programmed value of the I3CxBUFTHLD[RXSTART].
• The Response Queue is not full, and it has some space to hold the response for the current vendor-specific write transfer. Otherwise, the Target responds with a NACK for the vendor-specific directed write CCC transfer and ignores the broadcast vendor-specific write transfer.

Once the Vendor Specific directed CCC write address is acknowledged with ACK (accepted), the Target expects the RX FIFO space to be available until the end of the transfer to avoid an overflow condition. In the non-DMA mode of operation, use either the I3CxINTSTA [RXTHLDSTA] interrupt to free up the RX FIFO space while the RX data is being received, or configure the RX FIFO to accommodate the entire write transfer data (when the maximum write transfer size is defined and small). In the DMA mode of operation, the DMA request of the handshake interface is initiated when the RX FIFO level reaches the programmed I3CxBUFTHLD [RXBUF] level.

When an overflow condition is encountered (when the system latency is too high to consume the receiving data), the Target sets the I3CxCLTCCCSTAT [OVFLWERR] bit of the register and drops the further incoming data until the termination (either STOP or RESTART) is detected.

When a parity error is encountered during the vendor-specific CCC write transfer, the Controller sets the I3CxCLTCCCSTAT [PROTOERR] bit of the register and drops the further incoming data until the termination is detected.

Once the Target sets the overflow error or protocol error bit, it rejects (NACK) any further private or Vendor Specific CCC transfer requests from the Controller until the Controller reads the Target status through a GETSTATUS CCC, and the Target application resumes the Target operation by setting the bit I3CxCNTRL [RESUME].

If the receive FIFO does not have a threshold amount of space to accommodate the write transfer, the Controller NACKs the request and the I3CxCLTCCCSTAT [BUFFNTAVAIL] bit is set. Once the buffer not available bit is set, it rejects (NACKs) any further private or Vendor Specific CCC write transfer requests from the Controller until space is available in the receive FIFO. As the broadcast CCCs do not have any mechanism to NACK the incoming data, the incoming broadcast CCC is not sent to the user application.

The Target mentions the Vendor Specific CCC code along with the received data length (in bytes) in the generated response (retrieved from Response Queue I3CxRESPQUE) for the Vendor Specific CCC write transfer. The defining byte (if any) is passed to the application either through the Response Queue (for directed Vendor Specific CCC) or Rx-FIFO (for broadcast Vendor Specific CCC). The defining byte (if any) for broadcast Vendor Specific CCC is passed to Rx-FIFO as the Target cannot differentiate between the defining byte and the data payload.