The first byte of a SPI transaction consists of an R/W bit (R = 0, W = 1), followed by a 7-bit address, MSB-first. If the controller (host) is writing, then the second byte will be the data to be written. If the controller is reading, then the second byte sent on SPI_MOSI is ignored (except for CRC calculation).

If CRC is enabled, then the controller must send as the third byte the 8-bit CRC code, which is calculated over the first two bytes. If the CRC is correct, then the values clocked in will be put into the incoming buffer. If the CRC is not correct, then the outgoing buffer will be set to 0xFFFF, and the outgoing CRC will be set to 0xAA (these are clocked out on the next transaction).

During this transaction, the logic will clock out the contents of the outgoing buffer. If the outgoing buffer has not been updated since the last transaction, then the logic will clock out 0xFFFF, and if the CRC is clocked, it will clock out 0x00 for the CRC (if enabled). Thus the 0xFFFF00 will indicate to the controller that the outgoing buffer was not updated by the internal logic before the transaction occurred. This can occur when the device did not have sufficient time to update the buffer between consecutive transactions.

When the internal logic takes the write-data from the interface logic and processes it, it also causes the R/W bit, address, and data to be copied into the outgoing buffer. On the next transaction, this data is clocked back to the controller.

When the controller is initiating a read, the internal logic will put the R/W bit and address into the outgoing buffer, along with the data requested. The interface will compute the CRC on the two bytes in the outgoing buffer and clock that back to the controller if CRC is enabled (with the exceptions associated with 0xFFFF as noted above). A diagram of three transaction sequences with and without CRC are shown below, assuming CPOL=0.

The time required for the device to process commands and subcommands will differ based on the specifics of each. The direct commands generally will complete within 50 μs, while subcommands can take longer, with different subcommands requiring different duration to complete. For example, when a particular subcommand is sent, the device requires approximately 200 μs to load the 32-byte data into the internal subcommand buffer. If the host provides sufficient time for this load to complete before beginning to read the buffer (readback from addresses 0x40 to 0x5F), the device will respond with valid data, rather than 0xFFFF00. When data has already been loaded into the subcommand buffer, this data can be read back with approximately 50 μs interval between SPI transactions. The BQ76942 Technical Reference Manual provides more details on the approximate time duration required for specific commands and subcommands.

The host software should incorporate a scheme to retry transactions that may not be successful. For example, if the device returns 0xFFFFFF on SPI_MISO, then the internal clock is not powered, and the transaction needs to be retried. Similarly, if the device returns 0xFFFFAA on a transaction, this indicates the previous transaction encountered a CRC error, and so the previous transaction must be retried. As described above, if the device returns 0xFFFF00, then the previous transaction had not completed when the present transaction was sent, which may mean the previous transaction should be retried, or needs more time to complete.