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 is the data 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 is set to 0xFFFF, and the outgoing CRC is set to 0xAA (these are clocked out on the next transaction).

During this transaction, the logic clocks out the contents of the outgoing buffer. If the outgoing buffer was not 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 command indicates 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 puts the R/W bit and address into the outgoing buffer, along with the data requested. The interface computes the CRC on the two bytes in the outgoing buffer and clocks that back to the controller if CRC is enabled (with the exceptions associated with 0xFFFF, as noted above). Below are diagrams of transaction sequences with and without CRC, assuming CPOL = 0.

Figure 7-12 SPI Transaction #1 Using CRC

Figure 7-13 SPI Transaction #2 Using CRC

Figure 7-14 SPI Transaction #3 Using CRC

Figure 7-15 SPI Transaction #1 Without CRC

Figure 7-16 SPI Transaction #2 Without CRC

Figure 7-17 SPI Transaction #3 Without CRC

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. More detail regarding the approximate time duration required for specific commands and subcommands is provided in the BQ76972 Technical Reference Manual.

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 was not powered, and the transaction will need 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. And 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 at least needs more time to complete.