Serial Peripheral Interface (SPI)

The XBee 3 BLU supports SPI communications in slave mode. Slave mode receives the clock signal and data from the master and returns data to the master. The following table shows the signals that the SPI port uses on the device.

In this mode:

The following diagram shows frame format mode 0 for SPI communications.

SPI mode is chip to chip communication.

As a full-duplex protocol, SPI allows simultaneous transmission and reception of data, even if data is only available in one direction at a given time. This means that when the device receives data, it also transmits, although the received data is usually invalid. Likewise, when transmitting data, the device may receive invalid data. To manage this, the firmware encapsulates received data in API packets to identify its validity.

SPI enables valid data transmission from the slave device to begin at any point relative to when valid data is sent from the master. If the master sends data to the slave while the slave also has data to send, a full-duplex operation occurs, where both sides transmit and receive valid data simultaneously for a brief period. Both the master and slave must be capable of handling full-duplex operations and must adhere to the protocol for reliable communication.

The following figure illustrates the SPI interface while valid data is being sent in both directions.

Sleep modes generally work the same on SPI as they do on UART. However, the addition of SPI mode provides an option to configure another pin as a sleep pin.

By default, Digi configures D8 (DIO8/DTR/SLP_Request Configuration) as a peripheral and during pin sleep it wakes the device and puts it to sleep. This applies to both the UART and SPI serial interfaces.

If SLEEP_REQUEST is not configured as a peripheral and SPI_SSEL is configured as a peripheral, then pin sleep is controlled by SPI_SSEL rather than by SLEEP_REQUEST. Asserting SPI_SSEL by driving it low either wakes the device or keeps it awake. Negating SPI_SSEL by driving it high puts the device to sleep.

SPI_SSEL can be configured to both control sleep and to indicate that the SPI master has selected a particular slave device. This configuration provides an advantage where the pin sleep implementation on SPI mode requires one less physical pin. It does have the disadvantage that it puts the device to sleep whenever the SPI master unintentionally negates SPI_SSEL.

To effectively use the pin sharing configuration, the user/design must have control of the SPI_SSEL pin to the extent that it can control pin sleep. This makes the SLEEP_REQUEST pin available for a different purpose. Without control of SPI_SSEL while using it for sleep request, the device may go to sleep at inopportune times.

To force SPI mode on through-hole devices, hold DOUT/DIO13 low while resetting the device until SPI_ATTN asserts. This causes the device to disable the UART and go straight into SPI communication mode. Once configuration is complete, the device queues a modem status frame to the SPI port, which causes the SPI_ATTN line to assert. The host can use this to determine that the SPI port is configured properly.

On surface-mount devices, forcing DOUT low at the time of reset has no effect. To use SPI mode on the SMT modules, assert the SPI_SSEL low after reset and before any UART data is input.

Forcing DOUT low on TH devices forces the device to enable SPI support by setting the following configuration values to 1 (peripheral):

As long as the host does not issue a WR command, these configuration values revert to previous values after a power-on reset. If the host issues a WR command while in SPI mode, these same parameters are written to flash, and after a reset the device continues to operate in SPI mode.

If the UART is disabled and the SPI is enabled in the written configuration, then the device comes up in SPI mode without forcing it by holding DOUT low. If both the UART and the SPI are configured (P3 (DIO13/UART_DOUT Configuration) through P9 (DIO19/SPI_ATTN Configuration) are set to 1) at the time of reset, then output goes to the UART until the host sends the first input to the SPI interface. As soon as the first input comes on the SPI port, then all subsequent output goes to the SPI port and the UART is disabled.

After the first input arrives on the SPI port, all subsequent output goes to the SPI port and the UART is disabled.

When the master asserts the slave select (SPI_SSEL) signal, SPI transmit data is driven to the output pin SPI_MISO, and SPI data is received from the input pin SPI_MOSI. The SPI_SSEL pin has to be asserted to enable the transmit serializer to drive data to the output signal SPI_MISO. A rising edge on SPI_SSEL causes the SPI_MISO line to be tri-stated such that another slave device can drive it, if so desired.

If the output buffer is empty, the SPI serializer transmits the last valid bit repeatedly, which may be either high or low. Otherwise, the device formats all output in API mode 1 format, as described in the API mode section of the Operating mode page. The attached host is expected to ignore all data that is not part of a formatted API frame.

If you configure a device with only the SPI enabled and no SPI master is available to access the SPI slave port, you can recover the device to UART operation by holding DIN / CONFIG low at reset time.

DIN/CONFIG forces a default configuration on the UART at 9600 baud and brings up the device in Command mode on the UART port. You can then send the appropriate commands to the device to configure it for UART operation.

If you write those parameters, the device comes up with the UART enabled on the next reset.