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 clocks 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 clocks out 0x00 for the CRC (if enabled). Thus, 0xFFFF00 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 will place 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. For example, when the 0x0071 DASTATUS1() 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. Note that some commands or subcommands may take longer than 200 μs to complete. A notable exception is the IROM_SIG() subcommand, which takes approximately 9 ms to complete.

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.

The approximate time required to complete an operation based on the particular command or subcommand is shown below. Note that these times are only approximate and may vary depending on system operation at the time. Therefore, it is important that the host processor incorporate a retry scheme from the host processor, to handle communications errors or delays that may occur during operation.