Physical Interface

The module uses [Serial Peripheral Interface Bus] (SPI) OR [Universal Asynchronous Receiver/Transmitter] (UART) to communicate with a host processor. Note that the UART interface is only available with version 2.5.1 or later of module firmware. For more information about how to use each interface see Module Hardware Interface.

=ZigBee Common Signals= These are the same whether using SPI or UART.

Required Signals
RESET is used to hard reset the module and should always be controlled by the microcontroller

CFG0 and CFG1 are configuration pins. CFG0 is reserved for future use and CFG1 is used to select SPI or UART. This is only read at module startup.

Optional Signals
GPIO0, GPIO1, GPIO2, and GPIO3 are configurable general purpose input/output (GPIO) pins that may be read or written through the sysGpio library function.

=SPI= The SPI Interface must be configured as follows:
 * SPI master.
 * Clock speed must be greater than 500kHz and less than 4 MHz.
 * Clock polarity 0 and clock phase 0 on CC2530.
 * Bit order MSB first.

CFG0 and CFG1 are configuration pins. Connect as shown above

For more details or if you are writing your own firmware for the module, see CC2530 Pin Assignments.

Signals
MISO, MOSI, SS, and SCLK are the standard SPI signals.

MRDY is Master ReaDY, an active low signal. This signal is set by the application processor when it has data ready to send to the Module. This signal can either be controlled independently or it can be hardwired to the slave select signal. The documentation and code examples assume MRDY is hardwired to SS.

SRDY is Slave ReaDY, a bi-modal signal. This signal is set by the Module when it is ready to receive or send data. When asserted low, it indicates the Module is ready to receive data. When asserted high during an SPI POLL or SREQ transaction it indicates the Module is ready to send data. When asserted high during an SPI AREQ transaction it indicates the Module is done receiving data. In this manner SRDY has multiple functionality depending on whether you're waiting for data or whether the radio has data pending. See the examples.

MRDY must be asserted when communicating with the Module. If CS is connected to MRDY then you must leave it asserted between sending a SREQ and receiving a SRSP. If CS is controlled independently from MRDY then you must leave MRDY asserted between sending a SREQ and receiving a SRSP but you can de-assert CS inbetween. This is useful when you have multiple peripherals on the SPI bus and you don't want to tie up the bus waiting on the Module.

An example of how each signal is used is shown in the Reset_Module_Logic_Analyzer_Trace or Module Startup Logic Analyzer Trace - Coordinator.

Command Sequence

 * 1) The application processor initiates a transaction by setting MRDY low and then waits for SRDY to go low.
 * 2) The application processor shall never set MRDY high to end a transaction before all bytes of the frame have been transferred.
 * 3) When receiving a POLL or SREQ, the Module shall set SRDY high when it has data ready for the application processor.
 * 4) When receiving an AREQ, the Module shall set SRDY high when all bytes of the frame have been received.

=UART= The UART interface is easier to set up, but is slower than SPI and requires more housekeeping to be sure that messages are received fully before processing.

Signals
TX is the standard UART transmit line. Connect to a UART RX pin on a microcontroller.

RX is the standard UART receive line. Connect to a UART TX pin on a microcontroller.

CTS is active low and is read by the Module to determine whether the host microcontroller is ready to receive bytes. It should be connected to an output pin of a microcontroller.
 * High = Module won't send bytes
 * Low = Module will send bytes

RTS is active low and indicates whether the Module can receive bytes or else its input buffer is temporarily full. It should be connected to an input pin of a microcontroller.
 * High = Don't send bytes to the Module
 * Low = Module may receive bytes

Configuration
The UART is configured as follows:
 * Baud rate: 115200
 * Hardware (RTS/CTS) flow control.
 * 8-N-1 byte format.

The most common problem encountered with getting the UART interface working is with the flow control pins. Be sure that you configure all the pins correctly. Select the UART functionality on your microcontroller for the Tx/Rx signals and verify that the pin labeled "Tx" on the microcontroller is connected to the pin labeled "Rx" on the radio, and vice versa. You will need to configure the microcontroller signal for RTS (Ready to Send). The signal RTS is an OUTPUT from the Module and is asserted logic high when the Module is busy. This will typically be asserted on longer messages. This signal needs to be connected to an input pin on the microcontroller and the microcontroller MUST pause transmitting when this signal is asserted. In our sendMessage method, we simply check RTS prior to sending each byte, if RTS is asserted (logic high) then we just wait. For example:

//send message out to the radio for (char i = 0; i<bufIndex; i++) {  while (P1IN & BIT1) ;   			//P1.1 is RTS - if HIGH then do not send, just wait! while (!(UC1IFG&UCA1TXIFG));                // USCI_A1 TX buffer ready? UCA1TXBUF = c;                    		// TX  character } If using a Stellaris processor then you need to be a little careful, since these have a FIFO queue on the UART. Stopping sending bytes into the queue won't work; you need to stop the flow out of the queue. For example:

if (GPIOPinRead(GPIO_PORTD_BASE, RADIO_RTS)) 			       //if RTS is high (asserted) {  HWREG(UART1_BASE + UART_O_CTL) &= ~UART_CTL_TXE;  	//	...turn off UART TX } else {  							       //if RTS is low HWREG(UART1_BASE + UART_O_CTL) |= UART_CTL_TXE; 	//	...turn UART TX back on } Danger: If RTS is not configured correctly then some of the messages will work but the longer commands will not; the Module will just ignore them and behave erratically. CTS (Clear to Send) is an optional input to the Module to instruct it to pause transmitting. Use this if your application cannot receive a message or has a full buffer. It is optional and most applications don't use it. Please note: the UART interface is not supported on all hardware platforms.

Frame Format
UART packets wrap the generic frame format with a Start of Frame byte (0xFE) and a Frame Check Sequence.

The Frame Check Sequence is computed as an XOR of all the bytes in the general format frame fields. Shown below is a C example for the FCS calculation: unsigned char calcFCS(unsigned char *pMsg, unsigned char len) { unsigned char result = 0; while (len--) { result ^= *pMsg++; return result; Signal Description } } Commands sent to the module that lack either the SOF or correct FCS will be ignored.

=Generic Frame Format= All frames to/from the Module will follow this format:

The fields are as follows:
 * Length: The length of the data field of the frame.  The length can range from 0-250 bytes in length.
 * Command: The command of the frame.
 * Data: The frame data. This depends on the command field and is described for each command.

=Errors= If the Module cannot recognize a SREQ command then the Module will return the following command:

