The SPI Protocol

Single-byte commands have the following format:

Bit 7 (MSB)	6	Bits 5 through 0
Transfer	Direction	Length / 8 for transfer to slave; opcode for other commands

• Bit 7: Transfer - set when command is a data transfer.
• Bit 6: Direction - transfer direction (0 = MCU to module, 1 = module to MCU).
• Bits 5 - 0: Length - payload length (in 8-byte units).

With this format, these single-byte commands are defined:

• NUL (0) - used to poll status.
• Start Master Out: (0x80 thru 0xbf) - begin transfer from MCU to module.
• Start Master In: (0xf1) - begin transfer from module to MCU.
• Start Retry Master In: (0xf2) - (for error recovery) repeat of previous transfer from module to MCU.

All other commands are reserved.

NOTE

To form the Start Master Out command, round the packet length up to the next higher multiple of 8, then divide by 8 and add the constant 0x80. Length in the command allows module to start DMA before additional bytes are received. The packet length that forms the command does not include the command byte itself or the following two bytes of length, but does include the CRCCyclic Redundancy Check.

The MCU initiates all transfers. The module notifies the MCU of a transfer by setting the attention bit and asserting the INTR_N signal. The MCU controls the clock and, when the data transfer completes, stops the clock.

The following describes the transfer sequences for:

• Packet Transfers from the MCU to the Module
• Packet Transfers from the Module to the MCU
• Retry Packet Transfers from the Module to the MCU

Packet Transfers from the MCU to the Module

Transfers from the MCU to module start with the Master Out command byte, as follows:

1. Wait not busy - the MCU sends 0 bytes to the module and receives the status.

This is repeated until it sees a valid Status (bit 7 clear) and Not Busy (bit 0 clear). For some commands, ADS Busy (bit 3) must also be clear.

2. Start - the MCU sends Start Master Out command.

This contains the transfer length (8-byte multiples). Estimated length includes packet and CRC, rounded up to next multiple of 8. Opcode is 0x80 + (len + 7) / 8.

3. Wait busy - Each time MCU sends Start command, it receives the module Status byte.

This repeats until it sees the busy status (indicates module sees the command and is ready for the next part of the transfer).

4. Length - MCU sends the length (in bytes, MSB first) of the packet and CRCCyclic Redundancy Check. (Does not include command bytes or length.)

Value may be 1 through 384, inclusive.

5. Packet - MCU sends packet followed by CRC-8.
6. Padding bytes - MCU sends zero bytes to pad transfer to the rounded-up length that was used in the command byte.
7. Status - MCU sends zero bytes and waits for non-Busy status - and checks for Error status.

Return to the list of transfer sequences

Packet Transfers from the Module to the MCU

Transfers from the module to the MCU start at the MCU after it recognizes an interrupt from the module and/or an Attention status from the module. The transfer sequence is:

1. Wait not busy - the MCU sends 0 bytes to the module and receives the status.

This is repeated until the MCU receives a valid Status (bit 7 clear) and Not Busy (bit 0 clear) and Attention (bit 1).

2. Start - the MCU sends the Start Master In command, 0xf1. The received byte from module is examined.

The MCU repeats this until 0xf1 byte is received.

3. Module replies with Start - the module sends Start command byte to the MCU.

This indicates the length bytes to follow.

4. Length - the module sends transfer length (in bytes, MSBMost Significant Byte first), of packet and CRC-8.

Value may be 1 through 384, inclusive.

5. Payload - the MCU sends zero bytes to clock in the rest of the transfer.

The module sends the packet and the CRC.

Return to the list of transfer sequences

Retry Packet Transfers from the Module to the MCU

If the MCU detects a CRC error, the last transfer from the module can be re-tried (uses same procedure as initial receive transfer- except the start byte is 0xf2).

The MCU sends the 0xf2 start byte until it recognizes the 0xf1 byte from the module. The procedure is the same as Steps 3 through 5 under "Packet Transfers from the Module to the MCU" above.

Return to the list of transfer sequences

Possible error cases are as follows:

• Slave overrun in data - The MCU sends data faster than the module can get the data from data registers.

The module indicates that the transfer is complete with the status ERROR flag – and immediately ready for another transfer. When this occurs frequently – if using programmed I/O, slow the MCU transfer rate. If using DMADirect Memory Acess, reduce the SPI clock rate.

• Slave overrun in length - same as above (Slave overrun in data).

• Slave unresponsive - If the module does not set Busy flag soon after the MCU sends the Start byte (indicates a failure in module firmware).

Recovery action may involve a module reset.

• Master underrun - the does not send expected length to module.

This can occur if the MCU firmware error or module overrun in length transmission. If this occurs, the MCU can send zeros until the module Busy flag clears.

• Slave underrun - On transfers (the module to the MCU), the MCU paces the transfer - and the module cannot supply data fast enough.

Unlikely after length bytes are sent because module uses DMA. Problem is because data is still being transferred and MCU unable to determine a valid Status byte or just data. The MCU would detect this as a CRCCyclic Redundancy Check error. When this occurs frequently – if using programmed I/O, slow the MCU transfer rate. If using DMA, reduce SPI clock rate.

• CRC error - should not occur with functional hardware and software. If occurs in either direction, retry message several times - and count in error statistics.