Digi XBee-PRO XSC, XBEE-PRO S3, XBee-PRO 900HP, XBEE-PRO S3B User Manual
Digi International Inc.
11001 Bren Road East
Minnetonka, MN 55343
877 912-3444 or 952 912-3444
http://www.digi.com
XBee-PRO® 900HP/XBee-PRO® XSC RF Modules
XBee-PRO RF Modules by Digi International
Models: XBEE-PRO S3, XBEE-PRO S3B
Hardware: S3, S3B
90002173_L
2/4/2014
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
© 2014 Digi International Inc. All rights reserved
Nopartofthecontentsofthismanualmaybetransmittedorreproducedinany
formorbyanymeanswithoutthewrittenpermissionofDigiInternationalInc.
XBee‐PRO®isaregisteredtrademarkofDigiInternationalInc.
Technical Support: Phone: (866) 765-9885 toll-free U.S.A. & Canada
Online Support: http://www.digi.com/support
Email: rf-experts@digi.com
(801) 765-9885 Worldwide
8:00 am - 5:00 pm [U.S. Mountain Time]
©2014DigiInternationalInc. 2
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
Contents
1. Preface: How to Use this Manual 6
2. XBee-PRO 900HP RF Module Hardware 7
XBee-PRO S3B Hardware Description 7
Worldwide Acceptance 7
XBee-PRO 900HP Specifications 8
XBee-PRO 900HP Serial Communications
Specifications 9
UART 9
SPI 9
GPIO Specifications 9
Hardware Specifications for Programmable
Variant 10
XBee-PRO 900HP Mechanical Drawings 11
XBee-PRO 900HP Pin Signals 12
XBee-PRO 900HP Design Notes 12
XBee-PRO 900HP Power Supply Design 12
XBee-PRO 900HP Recommended Pin Connections
12
XBee-PRO 900HP Board Layout 13
XBee-PRO 900HP Module Operation for
Programmable Variant 13
XBee-PRO 900HP Programmable Bootloader 15
Overview 15
Bootloader Software Specifics 15
XBee-PRO 900HP Bootloader Menu Commands 19
XBee-PRO 900HP Firmware Updates 20
Output File Configuration 20
3. XBee-PRO 900HP RF Module Operation 22
XBee-PRO 900HP Basic Operational Design 22
XBee-PRO 900HP Serial Communications 22
XBee-PRO 900HP UART Data Flow 22
XBee-PRO 900HP SPI Communications 23
XBee-PRO 900HP SPI Operation 24
XBee-PRO 900HP Configuration 25
XBee-PRO 900HP Data Format 26
XBee-PRO 900HP SPI Parameters 26
XBee-PRO 900HP Serial Buffers 27
XBee-PRO 900HP UART Flow Control 27
XBee-PRO 900HP Serial Interface Protocols 28
XBee-PRO 900HP Modes of Operation 29
XBee-PRO 900HP Description of Modes 29
Transmit Mode 29
Receive Mode 31
Command Mode 31
Sleep Mode 32
4. XBee-PRO 900HP Networking Methods 33
MAC/PHY Basics 33
Related parameters: CM, HP, ID, PL, RR, MT 33
XBee-PRO 900HP Addressing Basics 33
Related parameters: SH, SL, DH, DL, TO 33
Point to Point/Multipoint (P2MP) 34
Throughput 34
Repeater/Directed Broadcast 34
Related parameters: CE, NH, NN, BH 34
DigiMesh Networking 35
Related Command: MR 35
DigiMesh Feature Set 35
Data Transmission and Routing 35
Transmission Timeouts 36
5. XBee-PRO 900HP Sleep Mode 38
Sleep Modes 38
Normal Mode (SM=0) 38
Asynchronous Pin Sleep Mode (SM=1) 38
Asynchronous Cyclic Sleep Mode (SM=4) 38
Asynchronous Cyclic Sleep with Pin Wake Up Mode
(SM=5) 39
Synchronous Sleep Support Mode (SM=7) 39
Synchronous Cyclic Sleep Mode (SM=8) 39
Asynchronous Sleep Operation 39
Wake Timer 39
XBee-PRO 900HP Indirect Messaging and Polling
(P2MP Packets Only) 40
Indirect Messaging 40
Polling 40
Synchronous Sleep Operation (DigiMesh
networks only) 40
Operation 40
Becoming a Sleep Coordinator 43
DigiMesh Configuration 44
DigiMesh Diagnostics 46
6. XBee-PRO 900HP Command Reference Tables 47
7. XBee-PRO 900HP API Operation 58
API Frame Format 58
XBee-PRO 900HP API Serial Exchanges 60
AT Commands 60
Transmitting and Receiving RF Data 60
Remote AT Commands 60
©2014DigiInternationalInc. 3
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
Contents
Supporting the API 61
XBee-PORO 900HP Frame Descriptions 61
AT Command 61
AT Command - Queue Parameter Value 62
TX Request 62
Explicit TX Request 63
Remote AT Command Request 65
AT Command Response 66
Modem Status 66
Transmit Status 67
Route Information Packet 67
Aggregate Addressing Update 69
RX Indicator 70
Explicit Rx Indicator 71
Data Sample RX Indicator 72
Node Identification Indicator 72
Remote Command Response 74
75
8. XBee-PRO 900HP Advanced Application Features
XBee-PRO 900HP Remote Configuration
Commands 75
Sending a Remote Command 75
Applying Changes on Remote Devices 75
Remote Command Responses 75
XBee-PRO 900HP Network Commissioning and
Diagnostics 75
XBee-PRO 900HP Device Configuration 75
XBee-PRO 900HP Network Link Establishm ent and
Maintenance 76
XBee-PRO 900HP Device Placement 76
XBee-PRO 900HP Device Discovery 77
XBee-PRO 900HP Link Reliability 78
Commissioning Pushbutton and Associate LED 81
XBee-PRO 900HP I/O Line Monitoring 82
I/O Samples 82
Queried Sampling 82
Periodic I/O Sampling 84
Digital I/O Change Detection 85
General Purpose Flash Memory 85
Accessing General Purpose Flash Memory 85
Over-the-Air Firmware Upgrades 91
Distributing the New Application 91
Verifying the New Application 92
Installing the Application 92
Things to Remember 92
Appendix A: XSC Firmware 93
XBee-PRO XSC Key Features 94
Worldwide Acceptance 94
Xbee-PRO XSC Specifications 94
XBee-PRO XSC Pin Signals 96
Xbee-PRO XSC Electrical Characteristics 97
XBee-PRO XSC Timing Specifications 97
XBee-PRO XSC Mechanical Drawings 98
Serial Communications 100
UART-Interfaced Data Flow 100
Serial Data 100
Flow Control 101
XBee-PRO XSC Modes of Operation 102
Idle Mode 102
Transmit Mode 102
Sleep Mode 104
Command Mode 106
XBee Programming Examples 109
AT Commands 109
Binary Commands 109
XBee-PRO XSC Command Reference Table 110
XBee-PRO XSC Command Descriptions 111
XBee-PRO XSC Addressing 129
Address Recognition 129
XBee-PRO XSC Basic Communications 130
Streaming Mode (Default) 130
Repeater Mode 131
XBee-PRO XSC Acknowledged Communications
135
Acknowledged Mode 135
Agency Certifications for S3B Hardware 138
FCC (United States) Certification 138
Labeling Requirements 138
FCC Notices 138
Limited Modular Approval 139
FCC-approved Antennas 139
IC (Industry Canada) Certification 139
IDA (Singapore) Certification 143
Brazil ANATEL 143
Agency Certifications for Legacy S3/S3B Hardware
144
FCC (United States) Certification 144
Labeling Requirements 144
FCC Notices 144
Limited Modular Approval 145
©2014DigiInternationalInc. 4
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
Contents
FCC-approved Antennas 145
IC (Industry Canada) Certification 145
ANATEL (Brazil) Certification 149
Additional Information 150
©2014DigiInternationalInc. 5
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
Preface:HowtoUsethisManual
This combined manual contains documentation for two hardware platforms: the S3 and S3B. Existing S3
customers are strongly encouraged to migrate their systems and designs to the newer and sup erior S3B
platform.
This manual also contains documentation for two RF protocols: XStream Compatible (XSC) and 900HP. The
XSC firmware is provided for customers who need compatibility with existing networks that need to be
9XStream compatible. Customers who do not require this compatibility should not use th e XSC firmware, but
rather the newer 900HP firmware.
Documentation for the XSC firmware is contained in Appendix A. All other firmware documentation in the
manual is not applicable to XSC firmware. Likewise documentation in Appendix A is not applicable to the
900HP firmware.
The following table describes how to use this manual based on the Digi part number for the module:
Digi Part
Numbers
XBP09-XC… MCQ-XBEEXSC S3 XSC XSC Appendix C
XBP9B-XC*T-001
(revision G and
earlier)
XBP9B-XC*T-002
(revision G and
earlier)
XBP9B-XC*T-021
(revision F and
earlier)
XBP9B-XC*T-022
(revision F and
earlier)
XBP9B-XC*T-001
(revision H and later)
XBP9B-XC*T-002
(revision H and later)
XBP9B-XC*T-021
(revision G and later)
XBP9B-XC*T-022
(revision G and later)
all other part numbers
beginning XBP9B-
XC...
XBP9B-D… MCQ-XB900HP S3B 900HP XSC / 900HP Appendix B
FCC ID
MCQ-XBPS3B S3B XSC XSC Appendix C
MCQ-XB900HP S3B XSC XSC / 900HP Appendix B
Hardware
Platform
Pre-installed
Firmware
Firmware
Available
Regulatory
Information
©2014DigiInternationalInc. 6
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
1.XBee‐PRO900HPRFModuleHardware
This manual describes the operation of the XBee-PRO® 900HP RF module, which consists of firmware loaded onto XBeePRO S3B hardware.
XBee-PRO 900HP embedded RF modules provide wireless connectivity to end-point devices in mesh networks. Utilizing
the XBee-PRO Feature S et, th ese module s are inte roper a ble wi th ot her devi ces. Wi th the XBee , us ers ca n ha v e t hei r network up-and-running in a matter of minutes without configuration or additional development.
XBee-PRO S3B Hardware Description
The XBee-PRO S3B radio module hardware consists of an Energy Micro EFM32G230F128 microcontroller, an
Analog Devices ADF7023 radio transceiver, an RF power amplifier, and in the programmable version, a
Freescale MC9S08QE32 microcontroller.
Worldwide Acceptance
FCC Certified (USA) - Refer to Appendix B for FCC Requirements.
Systems that include XBee-PRO Modules in herit Digi’s FCC Certification
ISM (Industrial, Scientific & Medical) frequency band
Manufactured under ISO 9001:2000 registered standards
XBee-PRO
RoHS compliant
®
(900 MHz) RF Modules are approved for use in U.S. and Canada.
©2014DigiInternationalInc. 7
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
XBee-PRO 900HP Specifications
SpecificationsoftheXBee-PRO® 900HP/XBee-PRO® XSCRFModule
Specification XBee
Performance
* Indoor/Urban Range
* Outdoor RF line-of-sight
Range
Transmit Power Output 24 dBm (250 mW) (software selectable)
RF Data Rate (High) 200 kbps
RF Data Rate (Low) 10 kbps
Serial UART interface CMOS Serial UART, baud rate stability of <1%
Serial Interface Data Rate
(software selectable)
Receiver Sensitivity
(typical)
Power Requirements
Supply Voltage
Transmit Current
Idle / Receive Current 29mA typical at 3.3V, (35mA max)
Sleep Current 2.5 µA (typical)
General
**Operating Frequency
Band
Dimensions
Weight 5 to 8 grams, depending on the antenna option
Operating Temperature -40º to 85º C (industrial)
Antenna Options
Digital I/O 15 I/O lines,
ADC 4 10-bit analog inputs
Networking & Security
Supported Network
Topologies
Number of Channels, user
selectable channels
Addressing Options PAN ID, Preamble ID, and 64-bit addresses
Encryption 128 bit AES
Agency Approvals
-101 dBm, high data rate, -110 dBm, low data rate
**Supply voltages of less than 3.0V may
result in reduced performance. Output
power and receiver sensitivity may be
1.297" x 0.962" x 0.215 (3.29cm x 2.44cm x 0.546cm) Note:
Dimensions do not include connector/antenna or pin lengths
Integrated wire, U. FL RF connector, Rev erse-polarity SMA
Mesh, point-to-point, point-to-multipoint, peer-to-peer
10kbps: up to 2000 ft (610m)
200kbps: up to 1000 ft (305m)
10kbps: up to 9 miles (15.5km)
200kbps: up to 4 miles (6.5km)
(with 2.1dB dipole antennas)
PL=4 : 215mA typical, (290mA max)
902 to 928 MHz (software selectable channels)
9600-230400 baud
2.1 to 3.6 VDC**
degraded.
PL=3 : 160mA typical
PL=2 : 120mA typical
PL=1 : 95mA typical
PL=0 : 60mA typical
connector
64 channels available
©2014DigiInternationalInc. 8
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
®
SpecificationsoftheXBee-PRO
Specification XBee
United States (FCC Part
15.247)
Industry Canada (IC) 1846A-XB900HP
Australia C-Tick
Brazil ANATEL 3727-12-1209 (S3B only)
Singapore License No. DA105737 (XB900HP only)
* To determine your range, perform a range test under your operating conditions.
900HP/XBee-PRO® XSCRFModule
MCQ-XB900HP
XBee-PRO 900HP Serial Communications Specifications
XBee RF modules support both UART (Universal Asynchronous Receiver / Transmitter) and SPI (Serial
Peripheral Interface) serial connections.
UART
UARTPinAssignments
UART Pins Module Pin Number
DOUT 2
DIN / CONFIG
/ DIO7 12
CTS
/ DIO6 16
RTS
3
More information on UART operation is found in the UART section in Chapter 2.
SPI
SPIPinAssignments
For more information on SPI operation, see the SPI section in Chapter 2.
GPIO Specifications
XBee RF modules have 15 GPIO (General Purpose Input/Output) ports available. The exact list will depend on
the module configuration, as some GPIO pins are used for purposes such as serial communication.
See GPIO section for more information on configuring and using GPIO ports.
ElectricalSpecificationsforGPIOPins
GPIO Electrical Specification Value
Voltage - Supply 2.1 - 3.6 V, (3.0V or higher required for optimal performance)
Low Schmitt switching threshold 0.3 x Vdd
High Schmitt switching threshold 0.7 x Vdd
Input pull-up resistor value 40 k
Input pull-down resistor value 40 k
Output voltage for logic 0 0.05 x Vdd
Output voltage for logic 1 0.95 x Vdd
SPI Pins Module Pin Number
SPI_SCLK / DIO18 18
SPI_SSEL
SPI_MOSI / DIO16 11
SPI_MISO / DIO15 4
/ DIO17 17
SPI_ATTN
/ DIO1 19
©2014DigiInternationalInc. 9
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
ElectricalSpecificationsforGPIOPins
GPIO Electrical Specification Value
Output source current 2 mA
Output sink current 2 mA
Total output current (for GPIO pins) 48 mA
Hardware Specifications for Programmable Variant
If the module has the programmable secondary processor, add the following table values to the specifications
listed on page 7. For example, if the secondary processor is running at 20 MHz and the primary processor is in
receive mode then the new current value will be I
runtime current of the secondary processor and I
Specificationsoftheprogrammablesecondaryprocessor
Optional Secondary Processor Specification
Runtime current for 32k running at 20MHz +14mA
Runtime current for 32k running at 1MHz +1mA
Sleep current +0.5A typical
For additional specifications see Freescale Datasheet and
Manual
Voltage requirement for secondary processor to operate at
maximum clock frequency
Minimum Reset Pulse for Programmable 100nS
Minimum Reset Pulse to Radio 50nS
VREF Range 1.8VDC to VCC
= Ir2 + I
total
is the receive current of the primary.
rx
= 14 mA + 9 mA = 23 mA, where I
rx
(Add to RX, TX, and sleep currents depending on
These numbers add to specifications
mode of operation)
MC9SO8QE32
2.4 to 3.6VDC
r2
is the
©2014DigiInternationalInc. 10
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
XBee-PRO 900HP Mechanical Drawings
MechanicaldrawingsoftheXBee‐PRO900HPRFModules(antennaoptionsnotshown).Alldimensionsareininches.
.
©2014DigiInternationalInc. 11
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
XBee-PRO 900HP Pin Signals
PinAssignmentsforXBeeModules
Pin # Name Direction Default State Description
1 VCC Power Supply
2 DOUT/DIO13 Both Output GPIO / UART Data out
3 DIN/nConfig/DIO14 Both Input GPIO / UART Data In
4 DIO12/SPI_MISO Both Output GPIO / SPI slave out
5 nRESET I nput
6 DIO10/PWM0
7 DIO11/PWM1 Both GPIO / Pulse Width Modulator
8 reserved Disabled Do Not Connect
9 nDTR/SLEEP_RQ/DIO8 Both Input
10 GND Ground
11 DIO4/AD4/SPI_MOSI Both GPIO/SPI slave In
12 nCTS/DIO7 Both Output GPIO / Clear-to-Send Flow Control
13 On_nSLEEP/DIO9 Output Output GPIO / Module Status Indicator
14 VREF Input
15 Associate/DIO5 Both Output GPIO / Associate Indicator
16 nRTS/DIO6 Both Input GPIO / Request-to-Send Flow Control
17 AD3/DIO3/SPI_nSSEL Both GPIO / Analog Input / SPI Slave Select
18 AD2/DIO2/SPI_CLK Both GPIO / Analog Input / SPI Clock
19 AD1/DIO1/SPI_nATTN Both GPIO / Analog Input / SPI Attention
20 AD0/DIO0 Both GPIO / Analog Input
(Low‐assertedsignalsaredistinguishedwithahorizontallineabovesignalname.)
Module Reset. Drive low to reset the modu le. This
is also an output with an open drain configuration
with an internal 20 K ohm pull-up (never drive to
logic high, as the module may be driving it low).
The minimum pulse width is 1 mS.
Both GPIO / RX Signal Strength Indicator
GPIO / Pin Sleep Control Line (DTR on the dev
board)
Internally used for programmable secondary
processor. For compatibility with other XBee
modules, we recommend connecting this pin to the
voltage reference if Analog Sampling is desired.
Otherwise, connect to GND.
• Signal Direction is specified with respect to the module
• See Design Notes section below for details on pin connections.
XBee-PRO 900HP Design Notes
The XBee modules do not specifically require any external circuitry or specific connections for proper
operation. However, t here are some general design guidelines that are recommended for help in
troubleshooting and building a robust design.
XBee-PRO 900HP Power Supply Design
Poor power supply can lead to poor radio performance, especially if the supply voltage is not kept within
tolerance or is excessively noisy. To help reduce noise, we recommend placing both a 1F and 47pF capacitor
as near to pin 1 on the PCB as possible. If using a switching regulator for your power supply, switching
frequencies above 500kHz are preferred. Power supply ripple should be limited to a maximum 50mV peak to
peak.
Note – For designs using the programmable modules, an additional 10F decoupling cap is recommended near
pin 1 of the module. The nearest proximity to pin 1 of the three caps should be in the following order: 47pf,
1F followed by 10F.
XBee-PRO 900HP Recommended Pin Connections
The only required pin connections are VCC, GND, DOUT and DIN. To support serial firmware updates, VCC,
GND, DOUT, DIN, RTS, and DTR should be connected.
©2014DigiInternationalInc. 12
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
All unused pins should be left disconnected. All inputs on the radio can be pulled high or low with 40k internal
pull-up or pull-down resistors using the PR and PD software commands. No specific treatment is needed for
unused outputs.
For applications that need to ensure the lowest sleep current, unconnected inputs should never be left
floating. Use internal or external pull-up or pull-down resistors, or set the unused I/O lines to outputs.
Other pins may be connected to external circuitry for convenience of operation, including the Associate LED
pin (pin 15) and the Commissioning pin (pin 20). An LED attached to the the associate LED pin will flash
differently depending on the state of the module to the network, and a pushbutton attached to pin 20 can
enable various join functions without having to send serial p ort commands. Please see the commissioning
pushbutton and associate LED section in chapter 7 for more details. The source and sink capabilities are
limited to 6mA on all I/O pins.
The VRef pin (pin 14) is only used on the programmable versions of these modules. For compatibility with
other XBee modules, we recommend connecting this pin to a voltage reference if analog sampling is desired.
Otherwise, connect to GND.
XBee-PRO 900HP Board Layout
XBee modules are designed to be self sufficient and have minimal sensitivity to nearby processors, cr ystals or
other PCB components. As with all PCB designs, Power and Ground traces should be thicker than signal traces
and able to comfortably support the maximum current specifications. No other special PCB design
considerations are required for integrating XBee radios except in the antenna section.
The choice of antenna and antenna location is very important for correct performance. XBees do not require
additional ground planes on the host PCB. In general , antenna elem ents r adiate perpendicular to the dire ction
they point. Thus a vertical antenna emits across the horizon. Metal objects near the antenna cause reflections
and may reduce the ability for an antenna to radiate efficiently. Metal objects between the transmitter and
receiver can also block the radiation path or reduce the transmission distance, so external antennas should be
positioned away from them as much as possible. Some objects that are often overlooked are metal poles,
metal studs or beams in structures, concrete (it is usually reinforced with metal rods), metal enclosures,
vehicles, elevators, ventilation ducts, refrigerators, microwave ovens, batteries, and t all electrolytic
capacitors.
XBee-PRO 900HP Module Operation for Programmable Variant
The modules with the programmable opti on have a s econdary processor with 32k of flash and 2k of RAM. This
allows module integrators to put custom code on the XBee module to fit their own unique needs. The DIN,
DOUT, RTS, CTS, and RESET lines are intercepted by the secondary processor to allow it to be in control of the
data transmitted and received. All other lines are in parallel and can be controlled by either the internal
microcontroller or the MC9SO8QE micro (see Block Diagram for details). The internal microcontroller by
default has control of certain lines. These lines can be released by the internal microcontroller by sending the
proper command(s) to disable the desired DIO line(s) (see XBee Command Reference Tables).
In order for the secondary processor to sample with ADCs, the XBee pin 14 (VREF) must be connected to a
reference voltage.
Digi provides a bootloader that can take care of programming the processor over the air or through the serial
interface. This means that over the air updates can be supported through an XMODEM protocol. The processor
can also be programmed and debugged through a one wire interface BKGD (Pin 8).
©2014DigiInternationalInc. 13
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
GND
A
5
4
G
E
12
9
ECO
PART NO.
B
14
2
13
11
REV
TITLE
DATE:
1
ENGINEER:
APPROVALS:
REV
DATE
10
17
16
15
8
3
F
APPR
CKD
BY
C
D
6
DESCRIPTION OF CHANGE
E
G
F
7
DESIGNED:
CHECKED:
DRAWN:
D
C
B
A
L
K
J
H
J
H
Digi Internat ional I nc
C
DOUT/PTB1
DIO3/ADC3/PTB5,A7/SS
BKGD/PTA4
DIO0/ADC0/PTA0
ON/SLEEP/PTA1
CTS/DIO7/PTC0
DIO4/PTB3/MOSI1
BKGD/PTA4
DIO12/PTB4/MISO1
DIN_RADIO
DOUT_RADIO
ASSOC/DIO5/PTD4
RTS/DIO6/PTD7
CTS_RADIO
VREF
CTS_RADIO
SLEEP_RQ/DTR/PTD5
RESET/PTA5
DIO1/ADC1/PTA3/SCL
RESET/PTA5
ASSOC/DIO5/PTD4
DIO2/ADC2/PTB2/SPSCK
DOUT_RADIO
DIN_RADIO
RESET_RADIO
ASSOC/DIO5/PTD4
ON/SLEEP/PTA1
ON/SLEEP/PTA1
RSSI/DIO10/PWM0/PTC 5
DIO1/ADC1/PTA3/SCL
VREF
RTS/DIO6/PTD7
DIO2/ADC2/PTB2/SPSCK
DIO3/ADC3/PTB5,A7/SS
RTS/DIO6/PTD7
DIO2/ADC2/PTB2/SPSC K
DIN/PTB0
VREF
DIO11/PWM1/PTA2/SDA
RTS_RADIO
DIO1/ADC1/PTA3/SCL
DIO12/PTB4/MISO1
DIN/PTB0
SLEEP_RQ/DTR/PTD5
DIO4/PTB3/MOSI1
BKGD/PTA4
DIN_RADIO
DIO12/PTB4/MISO1
DOUT_RADIO
CTS/DIO7/PTC0
DIO11/PWM1/PTA2/SDA
DIO0/ADC0/PTA0
RTS_RADIO
RTS_RADIO
DIO4/PTB3/MOSI1
DOUT/PTB1
CTS/DIO7/PTC0
DIO0/ADC0/PTA0
CTS_RADIO
RESET_RADIO
DIO3/ADC3/PTB5,A7/SS
RSSI/DIO10/PWM0/PTC 5
SLEEP_RQ/DTR/PTD5
RESET/PTA5
RSSI/DIO10/PWM0/PTC5
DIO11/PWM1/PTA2/SDA
RESET_RADIO
VCC
VCC
VCC
VCC
123456789
10
111213141516171819
20
VCC
GND
RESERVED
DIN/CONFIG
DOUT
DTR/SLEEP_RQ/DIO8
PWM0/RSSI/DIO10
PWM1/DIO11
RESET
PWM2/DIO12
CTS/DIO7
RTS/AD6/DIO6
VREF
AD1/DIO1
AD2/DIO2
DIO4
AD3/DIO3
AD0/DIO0
ASSOC/AD5/DIO5
ON/SLEEP/DIO9
S
2728474835363738101114152324252639404546161721
22
44434241291312
321343332201918
PTB6/SDA/XTAL
PTB1/KBI1P15/TxD1/ADP5
PTB2/KBIP6/SPSCK/ADP6
PTB3/KBIP7/MOSI/ADP7
PTB4/TPM2CH1/MISO
PTB5/TPM1CH1/SS
PTE6
PTD6/KBI2P6
PTA3/KBIP3/SCL/ADP3
PTA0/KBI1P0/TPM1CH0/ADP0/ACMP1+
PTA4/ACPM1O/BKGD/MS
PTA7/TPM2CH2/ADP9
PTA1/KBI1P1/TPM2CH0/ADP1/ACMP1-
PTA5/IRQ/TPM1CLK/RESET
PTA6/TPM1CH2/ADP8
PTA2/KBI1P2/SDA/ADP2
PTE4
PTE5
PTE3/SS
PTE2/MISO
PTD7/KBI2P7
PTD1/KBI2P1
PTD2/KBI2P2
PTD3/KBI2P3
PTD5/KBI2P5
PTE0/TPM2CLK/SPSCLK
PTD4/KBI2P4
PTB7/SCL/EXTEL
PTE1/MOSI
PTD0/KBI2P0
PTC4/TPM3CH4
PTB0/KBI1P4/RxD1/ADP4
PTC2/TPM3CH2
PTC7/TxD2/ACPM2-
PTC5/TPM3CH5/ACPM2O
PTC3/TPM3CH3
PTC1/TPM3CH1
PTC0/TPM3CH0
PTE7/TPM3CLK
PTC6/RxD2/ACPM2+
U1-A
MC9S08QE32CFT
304567893149
VSS
VSSAD
VREFL
VSS
VDD
VDD
VDDAD
PAD
VREFH
U1-B
MC9S08QE32CFT
14
8
Commissioning Line
19
10
20
1
9
6
354
2
FREESCALE
A
11
TP5
7
13
TP2
Pin10
Pin11
TP1
VREF must be connected to
external reference for MC9S08
to sample ADC lines
Special Test Points
TP6
XBEE-PRO S3B
PROGRAMMABLE
BLOCK DIAGRAM
TP4
15
Pin1
Pin20
Commissioning Line
MC9S08 controls
DOUT, DIN, RESET, RTS, CTS
for Internal Radio.
These lines are not
connected to the
20 external pins.
TP1
12
Pins PTE4, 5 and 6 are used so
software can determ
ine
fundamental Hardware differences
by turning on internal pull-up
resistors and reading the lines.
011 = Programmable S3B
PROGRAMMABLE XBEE-PRO S3B
16
TP2
18
TP5
TP4
17
TP6
S3B RADIO
©2014DigiInternationalInc. 14
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
XBee-PRO 900HP Programmable Bootloader
Overview
The XBee Programmable module is equipped with a Freescale MC9S08QE32 application processor. This
application processor comes with a supplied bootloader. This section describes how to interface the customer's
application code running on this processor to the XBee Programmable module's supplied bootloader.
The first section discusses how to initiate firmware updates using the supplied bootloader for wired and overthe-air updates.
Bootloader Software Specifics
Memory Layout
Figure 1 shows the memory map for the MC9S08QE32 application processor.
The supplied bootloader occupies the bottom pages of the flash from 0xF200 to 0xFFFF. Application
code cannot write to this space.
The application code can exist in Flash from address 0x8400 to 0xF1BC. 1k of Flash from 0x8000 to
0x83FF is reserved for Non Volatile Application Data that will not be erased by the bootloader during a
flash update.
A portion of RAM is accessible by both the application and the bootloader. Specifically, there is a shared
data region used by both the application and the bootloader that is located at RAM address 0x200 to
0x215. Application code should not write anything to BLResetCause or AppResetCause unless
informing the bootloader of the impending reset reason. The Application code should not clear
BLResetCause unless it is handling the unexpected reset reason.
T o prevent a malfunctioning application from running forever, the Bootloader increments BLResetCause
after each watchdog or illegal instruction reset. If this register reaches above 0x10 the bootloader will
stop running the application for a few minutes to allow an OTA or Local update to occur. If no update is
initiated within the time period, BLResetCause is cl ear ed and the application is started again. To
prevent unexpected halting of the application, the application shall clear or decrement BLResetCause
just before a pending reset. To disable this feature, the application shall clear BLResetCause at the
start of the application.
©2014DigiInternationalInc. 15
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
©2014DigiInternationalInc. 16
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
Operation
Upon reset of any kind, the execution control begins with the bootloader.
If the reset cause is Power-On reset (POR), Pin reset (PIN), or Low Voltage Detect (LVD) reset (LVD)
the bootloader will not jump to the application code if the override bits are set to RTS(D7)=1,
DTR(D5)=0, and DIN(B0)=0. Otherwise, the bootloader writes the reset cause "NOTHING" to the
shared data region, and jumps to the Application.
Reset causes are defined in the file common. h in an enumeration with the following definitions:
typedef enum {
BL_CAUSE_NOTHING = 0x0000, //PIN, LVD, POR
BL_CAUSE_NOTHING_COUNT = 0x0001,//BL_Reset_Cause counter
// Bootloader increments cause every reset
BL_CAUSE_BAD_APP = 0x0010,//Bootloader considers APP invalid
} BL_RESET_CAUSES;
typedef enum {
APP_CAUSE_NOTHING = 0x0000,
APP_CAUSE_USE001 = 0x0001,
// 0x0000 to 0x00FF are considered valid for APP use.
APP_CAUSE_USE255 = 0x00FF,
APP_CAUSE_FIRMWARE_UPDATE = 0x5981,
APP_CAUSE_BYPASS_MODE = 0x4682,
APP_CAUSE_BOOTLOADER_MENU = 0x6A18,
} APP_RESET_CAUSES;
Otherwise, if the reset cause is a "watchdog" or other reset, the bootloader checks the shared memory
region for the APP_RESET_CAUSE. If the reset cause is:
1."APP_CAUSE_NOTHING" or 0x0000 to 0x00FF, the bootloader increments the
BL_RESET_CAUSES, verifies that it is still less than BL_CAUSE_BAD_APP , and jumps back to
the application. If the Application does not clear the BL_RESET_CAUSE, it can prevent an
infinite loop of running a bad application that continues to perform illegal instructions or
watchdog resets.
2."APP_CAUSE_FIRMWARE_UPDATE", the bootloader has been instructed to update the
application "over-the-air" from a specific 64-bit address. In this case, the bootloader will
attempt to initiate an Xmodem transfer from the 64-bit address located in shared RAM.
3."APP_CAUSE_BYPASS_MODE", the bootloader executes bypass mode. This mode passes the
local UART data direc tly to the internal mi crocontroller allowing for dire ct communicati on with
the internal microcontroller.
The only way to exit bypass mode is to reset or power cycle the module.
If none of the above is true, the bootloader will enter "Command mode". In this mode, users can
initiate firmware downloads both wired and over-the-air, check application/bootloader version strings,
and enter Bypass mode.
Application version string
Figure 1 shows an "Application version string pointer" area in application flash which holds the pointer
to where the application version string resides. The application's linker command file ultimately
determines where this string is placed in application flash.
It is preferable that the application version string be loca ted at address 0x8400 for MC9S08QE32 parts .
The application string can be any characters terminated by the NULL character (0x00). There is not a
strict limit on the number of characters in the string, but for practical purposes should be kept under
100 bytes including the terminating NULL character. During an update the bootloader erases the entire
application from 0x8400 on. The last page has the vector table specifically the redirected reset vec to r.
The version string pointer and reset vector are used to determine if the application is valid.
©2014DigiInternationalInc. 17
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
Application Interrupt Vector table and Linker Command File
Since the bootloader flash region is read-only, the interrupt vector table is redirected to the region
0xF1C0 to 0xF1FD so that application developers can use hardware interrupts. Note that in order for
Application interrupts to function properly, the Application's linker command file (*.prm extension)
must be modified appropriately to allow the linker to place the developers code in the correct place in
memory. For example, the developer desires to use the serial communications port SCI1 receive
interrupt. The developer would add the following line to the Codewarrior linker command file for the
project:
VECTOR ADDRESS 0x0000F1E0 vSci1Rx
This will inform the linker that the interrupt function "vSci1Rx()" should be placed at address
0x0000F1E0. Next, the developer should add a file to their project "vector_table.c" that creates an
array of function pointers to the ISR routines used by the application.
extern void _Startup(void);/* _Startup located in Start08.c */
extern void vSci1Rx(void);/* sci1 rx isr */
extern short iWriteToSci1(unsigned char *);
void vDummyIsr(void);
#pragma CONST_SEG VECTORS
void (* const vector_table[])(void) = /* Relocated Interrupt vector table */{
vDummyIsr,/* Int.no. 0 Vtpm3ovf (at F1C0)Unassigned */
vDummyIsr, /* Int.no. 1 Vtpm3ch5 (at F1C2) Unassigned */
vDummyIsr, /* Int.no. 2 Vtpm3ch4 (at F1C4) Unassigned */
vDummyIsr, /* Int.no. 3 Vtpm3ch3 (at F1C6) Unassigned */
vDummyIsr, /* Int.no. 4 Vtpm3ch2 (at F1C8) Unassigned */
vDummyIsr, /* Int.no. 5 Vtpm3ch1 (at F1CA) Unassigned */
vDummyIsr, /* Int.no. 6 Vtpm3ch0 (at F1CC) Unassigned */
vDummyIsr, /* Int.no. 7 Vrtc (at F1CE) Unassigned */
vDummyIsr, /* Int.no. 8 Vsci2tx (at F1D0) Unassigned */
vDummyIsr, /* Int.no. 9 Vsci2rx (at F1D2) Unassigned */
vDummyIsr, /* Int.no. 10 Vsci2err (at F1D4) Unassigned */
vDummyIsr, /* Int.no. 11 Vacmpx (at F1D6) Unassigned */
vDummyIsr, /* Int.no. 12 Vadc (at F1D8) Unassigned */
vDummyIsr, /* Int.no. 13 Vkeyboard (at F1DA) Unassigned */
vDummyIsr, /* Int.no. 14 Viic (at F1DC) Unassigned */
vDummyIsr, /* Int.no. 15 Vsci1tx (at F1DE) Unassigned */
vSci1Rx, /* Int.no. 16 Vsci1rx (at F1E0) SCI1RX */
vDummyIsr, /* Int.no. 17 Vsci1err (at F1E2) Unassigned */
vDummyIsr, /* Int.no. 18 Vspi (at F1E4) Unassigned */
vDummyIsr, /* Int.no. 19 VReserved12 (at F1E6) Unassigned */
vDummyIsr, /* Int.no. 20 Vtpm2ovf (at F1E8) Unassigned */
vDummyIsr, /* Int.no. 21 Vtpm2ch2 (at F1EA) Unassigned */
vDummyIsr, /* Int.no. 22 Vtpm2ch1 (at F1EC) Unassigned */
vDummyIsr, /* Int.no. 23 Vtpm2ch0 (at F1EE) Unassigned */
vDummyIsr, /* Int.no. 24 Vtpm1ovf (at F1F0) Unassigned */
vDummyIsr, /* Int.no. 25 Vtpm1ch2 (at F1F2) Unassigned */
vDummyIsr, /* Int.no. 26 Vtpm1ch1 (at F1F4) Unassigned */
vDummyIsr, /* Int.no. 27 Vtpm1ch0 (at F1F6) Unassigned */
©2014DigiInternationalInc. 18
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
vDummyIsr, /* Int.no. 28 Vlvd (at F1F8) Unassigned */
vDummyIsr, /* Int.no. 29 Virq (at F1FA) Unassigned */
vDummyIsr, /* Int.no. 30 Vswi (at F1FC) Unassigned */
_Startup /* Int.no. 31 Vreset (at F1FE) Reset vector */
};
void vDummyIsr(void){
for(;;){
if(iWriteToSci1("STUCK IN UNASSIGNED ISR\n\r>"));
}
}
The interrupt routines themselves can be defined in separate files. The "vDummyIsr" function is used
in conjunction with "iWritetoSci1" for debugging purposes.
XBee-PRO 900HP Bootloader Menu Commands
The bootloader accepts commands from both the local UART and OTA. All OTA commands sent must be
Unicast with only 1 byte in the payload for each command. A response will be returned to the sender. All
Broadcast and multiple byte OTA packets are dropped to help prevent general OTA traffic from being
interpreted as a command to the bootloader while in the menu.
Bypass Mode - "B"
The bootloader provides a “bypass” mode of operation that essentially connects the freescale mcu to
the internal microcontroller’s serial UART. This allows direct communication t o the internal
microcontroller’s radio for the purpose of firmware and radio configuration changes. Once in bypass
mode, the X-CTU utility can change modem configuration and/or update module’s firmware. Bypass
mode automatically handles any baud rate up to 115.2kbps. Note that this command is unavailable
when module is accessed remotely.
Update Firmware - "F"
The "F" command initiates a firmware download for both wired and over-the-air configurations.
Depending on the source of the command (received via Over the Air or local UART), the download will
proceed via wired or over-the-air respectively.
Adjust Timeout for Update Firmware - "T"
The "T" command changes the timeout before sending a NAK by Base-Time*2^(T). The Base- Time for
the local UART is different than the Base-Time for Over the Air. During a firmware update, the
bootloader will automatically increase the Timeout if repeat packets are received or multiple NAKs for
the same packet without success occur.
Application Version String - "A"
The "A" command provides the version of the currently loaded application. If no application is present,
"Unkown" will be returned.
Bootloader Version String - "V"
The "V" command provides the version of the currently loaded bootloader. The version will return a
string in the format BLFFF-HHH-XYZ_DDD where FFF repr esents the Flash size in kilo bytes, HHH is the
hardware, XYZ is the version, and DDD is the preferred XMODEM packet size for updates. Double the
preferred packet size is also possible, but not guaranteed. For example "BL032-2 B0-023_064" will ta ke
64 byte CRC XMODEM payloads and may take 128 byte CRC XMODEM payloads also. In this case, both
64 and 128 payloads are handled, but the 64 byte payload is preferred for better Over the Air
reliability.
Bootloader Version BL032-2x0-025_064 only operates at 9600 baud on the local UART as well as
communications to the internal microc ontroller. A newer version of the Bootloader BL032-2x0-033_064
or newer BL032-2B0-XXX_064 has changed the baud rate to 115200 between the Programmable and
©2014DigiInternationalInc. 19
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
the internal microcontroller. The internal module is also set to 115200 as the default baud rate. The
default rate of the programmable local UART is also set to 115200, however, the local UART has an
auto baud feature added to detect if the UART is at the wrong baud rate. If a single character is sent, it
will automatically switch to 115200 or 9600 baud.
XBee-PRO 900HP Firmware Updates
Wired Updates
A user can update their application using the bootloader in a wired configuration with the following
steps:
a. Plug XBee programmable module into a suitable serial port on a PC.
b. Open a hyperterminal (or similar dumb terminal application) session with 115200 baud, no par-
ity, and 8 data bits with one stop bit.
c. Hit Enter to display the bootloader menu.
d. Hit the "F" key to initiate a wired firmware update.
e. A series of "C" characters Will be displayed within the hyperterminal window. At this point,
select the "transfer->send file" menu item. Select the desired flat binary output file.
f. Select "Xmodem" as the protocol.
g. Click "Send" on the "Send File" dialog. The file will be downloaded to the XBee Programmable
module. Upon a successful update, the bootloader will jump to the newly loaded application.
Over-The-Air updates
A user can update their application using the bootloader in an “over-the-air” configuration with the
following steps…(This procedure assumes that the bootloader is running and not the application. The
internal microcontroller baud rate of the programmable module must be set to 115200 baud. The
bootloader only operates at 115200 baud between the Radio and programmable bootloader. The
application must be programmed with some way to support returning to the bootloader in order to
support Over the Air (OTA) updates without local intervention.)
a. Open a hyperterminal session to the host module with no parity, no hardwareflow control, 8
data bits and 1 stop bit. (The host module does not have to operate at the same baud rate as the
remote module.) For faster updates and less latency due to the UART, set the host module to a
faster baud rate. (i.e. 115200)
b. Enter 3 pluses "+++" to place the module in command mode. (or XCTU’s “Modem Configuration” tab can be used to set the correct parameters)
c. Set the Host Module destination address to the target module’s 64 bit address that the host
module will update (ATDH aabbccdd, ATDL eeffgghh, ATCN, where aabbccddeeffgghh is the hexadecimal 64 bit address of the target module).
d. Hit Enter and the bootloader command menu will be displayed from the remote module. (Note
that the option "B" doesn't exist for OTA)
e. Hit the "F" key to cause the remote module to request the new firmware file over-the-air.
f. The host module will begin receiving "C" characters indicating that the remote module is
requesting an Xmodem CRC transfer. Using XCTU or another terminal program, Select "XMODEM"
file transfer. Select the Binary file to upload/transfer. Click Send to start the transfer. At the conclusion of a successful transfer, the bootloader will jump to the newly loaded application.
Output File Configuration
BKGD Programming
P&E Micro provides a background debug tool that allows flashing applications on the MC9S08QE parts
through their background debug mode port. By default, the Codewarrior tool produces an "ABS" output
file for use in programming parts through the background debug interface. The programmable XBee
from the factory has the BKGD debugging capability disabled. In order to debug, a bootloader with the
©2014DigiInternationalInc. 20
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
debug interface enabled needs to be loaded on the secondary processor or a stand-alone app needs to
be loaded.
Bootloader updates
The supplied bootloader requires files in a "flat binary" format which differs from the default ABS file
produced. The Codewarrior tool also produces a S19 output file. In order to successfully flash new
applications, the S19 file must be converted into the flat binary format. Utilities are available on the
web that will convert S19 output to "BIN" outputs. Often times, the "BIN" file conversion will pad the
addresses from 0x0000 to the code space with the same number. (Often 0x00 or 0xFF) These extra
bytes before the APP code starts will need to be deleted from the bin file before the file can be
transferred to the bootloader.
©2014DigiInternationalInc. 21
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
Packet Handler
Transparent
Mode
AT Command
Mode
API
Mode
Network Layer (DigiMesh/Repeater)
MAC/PHY Layer (Point-Multipoint)
UART SPI
2.XBee‐PRO900HPRFModuleOperation
XBee-PRO 900HP Basic Operational Design
The XBee-PRO® 900HP RF Module uses a multi-layered firmware base to order the flow of data, dependent on the
hardware and software configuration chosen by the user. This configuration block diagram is shown below, with the
host serial interface as the physical starting point, and the antenna as the physical endpoint for the transferred data.
As long as a block is able to touch another block, the two interfaces can interact. For example, if the module is using
SPI mode, Transparent Mode is not available. See below:
Host Serial Interface
Command Handler
Antenna
The command handler is the code that processes commands from AT Command Mode or API Mode (see AT Commands section). The command handler can also proces s commands from re mote r adios ( see Remote AT Command s
section).
XBee-PRO 900HP Serial Communications
XBee RF Modules interface to a host device through a serial port. Through its serial port, the module can
communicate with any logic and voltage compatible UART, through a level translator to any serial device (for
example, through a RS-232 or USB interface board), or through a Serial Peripheral Interface (SPI), which is a
synchronous interface to be described later.
XBee-PRO 900HP UART Data Flow
Devices that have a UART interface can connect directly to the pins of the RF module as shown in the figure
below.
SystemDataFlowDiagraminaUART‐interfacedenvironment
(Low‐assertedsignalsdistinguishedwithhorizontallineoversignalname.)
©2014DigiInternationalInc. 22
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
Serial Data
Data enters the module UART through the DIN (pin 3) as an asynchronous serial signal. The signal should
idle high when no data is being transmitted.
Each data byte consists of a start bit (low), 8 data bits (least signif ic ant bit first) and a stop bit (high). The
following figure illustrates the serial bit pattern of data passing through the module.
UARTdatapacket0x1F(decimalnumberʺ31ʺ)astransmittedthroughtheRFmodule
ExampleDataFormatis8‐N‐1(bits‐parity‐#ofstopbits)
Serial communications depend on the two UARTs (the microcontroller's and the RF module's) to be
configured with compatible settings (baud rate, parity, start bits, stop bits, data bits).
The UART baud rate, parity, and stop bits settings on the XBee module can be configured with the BD, NB,
and SB commands respectively. See the command table in chapter 10 for details.
XBee-PRO 900HP SPI Communications
The XBee modules support SPI communications in slave mode. Sla ve mode receiv es the clock signal and data
from the master and returns data to the master. The SPI port uses the following signals on the XBee:
• SPI_MOSI (Master Out, Slave In) - inputs serial data from the master
• SPI_MISO (Master In, Slave Out) - outputs serial data to the master
• SPI_SCLK (Serial Clock) - clocks data transfers on MOSI and MISO
•SPI_SSEL
•SPI_ATTN
ule will assert this pin as soon as data is available to send to the SPI master and it will remain
asserted until the SPI master has clocked out all available data.
In this mode, the following apply:
• SPI Clock rates up to 3.5 MHz are possible.
• Data is MSB first
• Frame Format mode 0 is used. This means CPOL=0 (idle clock is low) and CPHA=0 (data is
sampled on the clock’s leading edge). Mode 0 is diagramed below.
• SPI port is setup for API mode and is equivalent to AP=1.
(Slave Select) - enables serial communication with the slave
(Attention) - alerts the master that slave has data que ued to send. The XBee mod-
FrameFormatforSPICommunications
©2014DigiInternationalInc. 23
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
XBee-PRO 900HP SPI Operation
This section specifies how SPI is implemented on the XBee, what the SPI signals are, and how full duplex
operations work.
XBee Implementation of SPI
The module operates as a SPI slave only. This means that an external master will provide the clock and will
decide when to send. The XBee-PRO 900HP supports an external clock rate of up to 3.5 Mbps.
Data is transmitted and received with most significant bit first using SPI mode 0. This means the CPOL and
CPHA are both 0. Mode 0 was chosen because it's the typical default for most microcontrollers and would
simplify configuration of the master. Further information on Mode 0 is not included in this manual, but is welldocumented on the internet.
XBee-PRO 900HP SPI Signals
The official specification for SPI includes the four sign als SPI_MISO, SPI_MOSI, SPI_CLK, and SPI_SSEL.
Using only these four signals, the master cannot know when the sl ave needs to se nd and the SPI slav e cannot
transmit unless enabled by the master. For this reason, the SPI_ATTN
allows the module to alert the SPI master that it has data to send. In turn, the SPI master is expected to
assert SPI_SSEL
in turn, allows the XBee module to send data to the master.
The table below names the SPI signals and specifies their pinouts. It also describes the operation of each pin:
and start SPI_CLK, unless these signals are already asserted and active respectively. This,
signal is available in the design. This
Signal Name Pin Number
SPI_MISO
(Master In, Slave out)
SPI_MOSI
(Master out, Slave in)
SPI_SSEL
(Slave Select)
(Master out, Slave in)
SPI_CLK
(Clock)
(Master out, Slave in)
SPI_ATTN
(Attention)
(Master in, Slave out)
Note: By default, the inputs have pull-up resistors enabled. See the PR command to disable the pull-up
resistors. When the SPI pins are not connected but the pins are configured for SPI operation , then the pull-ups
are needed for proper UART operation.
Full Duplex Operation
SPI on XBee requires usage of API mode (without escaping) to packetize data. However, by design, SPI is a
full duplex protocol, even when data is only available in one direction. This means that whenever data is
received, it will also transmit, and that data will normally be invalid. Likewise, whenever data is transmitted,
invalid data will probably be received. The means of determining whether or not received data is invalid is by
packetizing the data with API packets.
SPI allows for valid data from the slave to begin before, at the same time, or after valid data begins from the
master. When the master is sending data to the slave and the slave has valid data to send in the middle of
receiving data from the master, this allows a true full duplex operation where data is valid in both directions
for a period of time. Not only must the master and the slave both be able to keep up with the full duplex
operation, but both sides must honor the protocol as specified.
An example follows to more fully illustrate the SPI interface while valid data is being sent in both directions.
4ATP2
11 ATD4
17 ATD3
18 ATD2
19 ATD1
Applicable AT
Command
Description
When SPI_SSEL
the module outputs the data on this line at the SPI_CLK
rate. When SPI_SSEL
should be tri-stated such that another slave device can
drive the line.
The SPI master outputs data on this line at the SPI_CLK
rate after it selects the desired slave. When the module is
configured for SPI operations, this pin is an input.
The SPI master outputs a low signal on this line to select
the desired slave. When the module is configured for SPI
operations, this pin is an input.
The SPI master outputs a clock on this pin, and the rate
must not exceed the maximum allowed, 3.5 Mbps. When
the module is configured for SPI operations, this pin is an
input.
The module asserts this pin low when it has data to send to
the SPI master. When this pin is configured for SPI
operations, it is an output (not tri-stated).
is asserted (low) and SPI_CLK is active,
is de-asserted (high), this output
©2014DigiInternationalInc. 24
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
Low Power Operation
In general, sleep modes work the same on SPI as they do on UART. However, due to the addition of SPI
mode, there is the option of another sleep pin, as described below:
By default, DIO8 (SLEEP_REQUEST) is configured as a peripheral and is used for pin sleep to awaken and to
sleep the radio. This applies regardless of the selected serial interface (UART or SPI).
However, if SLEEP_REQUEST is not configured as a peripheral and SPI_SSEL
then pin sleep is controlled by SPI_SSEL
either awakens the radio or keeps it awake. Negating SPI_SSEL
Using SPI_SSEL
particular slave device) has the advantage of requiring one less physical pin connection to implement pin sleep
on SPI. It has the disadvantage of putting the radio to sleep whenever the SPI master negates SPI_SSEL
(meaning time will be lost waiting for the device to wake), even if that wasn't the intent. Therefore, if the user
has full control of SPI_SSEL
sharing the pin may be a good option in order to make the SLEEP_REQUEST pin av ailable for another purpose.
If the radio is one of multiple slaves on the SPI, then the radio would sleep while the SPI master talks to the
other slave, but this is acceptable in most cases.
If neither pin is configured as a peripheral, then the radio stays awake, being unable to sleep in SM1 mode.
for two purposes (to control sleep and to indicate that the SPI master has selected a
so that it can control pin sleep, whether or not data needs to be transmitted, then
rather than by SLEEP_REQUEST. Asserting SPI_SSEL by driving it low
by driving it high puts the radio to sleep.
is configured as a peripheral,
XBee-PRO 900HP Configuration
The three considerations for configuration are:
•How is the serial port selected? (I.e. Should the UART or the SPI port be used?)
•If the SPI port is used, what should be the format of the data in order to avoid processing invalid
characters while transmitting?
•What SPI options need to be configured?
Serial Port Selection
In the default configuration the UART and SPI ports will both be configured for serial port operation.
If both interfaces are configured, serial data will go out the UART until the SPI_SSEL
Thereafter, all serial communications will operate on the SPI interface.
signal is asserted.
©2014DigiInternationalInc. 25
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
If only the UART is enabled, then only the UART will be used, and SPI_SSEL will be ignored. If only the SPI is
enabled, then only the SPI will be used.
If neither serial port is enabled, the module will not support serial operations and all communications must
occur over the air. All data that would normally go to the serial port is discarded.
Forcing UART Operation
In the rare case that a module has been configured with only the SPI enabled and no SPI master is available
to access the SPI slave port, the module may be re covered to UAR T operation by holding DIN / CONFIG
reset time. As always, DIN/CONFIG
up the module in command mode on the UART port. Appropriate commands can then be sent to t he module to
configure it for UART operation. If those parameters are written, then the module will come up with the UART
enabled, as desired on the next reset.
SPI Port Selection
SPI mode can be forced by holding DOUT/DIO13 (pin 2) low while resetting the module until SPI_nATTN
asserts. By this means, the XBee module will disable the UART and go straight into SPI communication mode.
Once configuration is completed, a modem status frame is queued by the module to the SPI port which will
cause the SPI_nATTN line to assert. The host can use thi s to dete rmine th at the SPI port has been co nfigu red
properly. This method internally forces the configuration to provide full SPI support for the following
parameters:
•D1 (note this parameter will only be changed if it is at a default of zero when method is invoked)
•D2
•D3
•D4
•P2.
As long as a WR command is not issued, these configuration values will revert back to previous values after a
power on reset. If a WR command is issued while in SPI mode, these same parameters will be written to flash.
After a reset, parameters that were forced and then written to flash become the mode of operation. If the
UART is disabled and the SPI is enabled in the written configuration, t h en the module will come up in SPI
mode without forcing it by holding DOUT low. If both the UART and the SPI are enabled at the time of reset,
then output will go to the UART until the host sends the first input. If that first input comes on the SPI port,
then all subsequent output will go to the SPI port and the UART will be disabled. If the first input comes on the
UART, then all subsequent output will go to the UART and the SPI will be disabled.
When the slave select (SPI_nSSEL) signal is asserted by the master, SPI transmit data is driven to the output
pin SPI_MISO, and SPI data is received from the input pin SPI_MOSI. The SPI_nSSEL pin has to be asserted
to enable the transmit serializer to drive data to the output signal SPI_MISO. A rising edge on SPI_nSSEL
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 module formats all output in API mode 1 format, as described in chapter 7. The
attached host is expected to ignore all data that is not part of a formatted API frame.
low at
forces a default configuration on the UART at 9600 baud and it will bring
XBee-PRO 900HP Data Format
The SPI will only operate in API mode 1. Neither transparent mode nor API mode 2 (which escapes control
characters) will be supported. This means that the AP configuration only applies to the UART and will be
ignored while using the SPI.
XBee-PRO 900HP SPI Parameters
Most host processors with SPI hardware allow the bit order, clock phase and polarity to be set. For
communication with all XBee radios the host processor must set these options as follows:
•Bit Order - send MSB first
•Clock Phase (CPHA) - sample data on first (leading) edge
•Clock Polarity (CPOL) - first (leading) edge rises
This is SPI Mode 0 and MSB first for all XBee radios. Mode 0 means that data is sampled on the leading edge
and that the leading edge rises. MSB first means that bit 7 is the first bit of a byte sent over the interface.
©2014DigiInternationalInc. 26
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
XBee-PRO 900HP Serial Buffers
T o enable the UAR T port, DIN and DOUT must be configured as peripher als. To enable the SPI port, SPI_MISO,
SPI_MOSI, SPI_SSEL
go to the UART until the first input on SPI.
When both the UART and SPI ports are enabled on power-up, all serial data will go out the UART. But, as soon
as input occurs on either port, that port is selected as the active port and no input or output will be allowed on
the other port until the next reset of the module.
If the configuration is changed so that only one port is configured, then that port will be the only one enabled
or used. If the parameters are written with only one port enabled, then the port that is not enabled will not
even be used temporarily after the next reset.
If both ports are disabled on reset, the UART will be used in spite of the wrong configuration so that at least
one serial port will be operational.
Serial Receive Buffer
When serial data enters the RF module through the DIN Pin (or the MOSI pin), the data is stored in the
serial receive buffer until it can be processed. Under certain conditions, the module may not be able to
process data in the serial receive buffer immediately. If large amounts of serial data are sent to the module
such that the serial receive buffer would overflow, then the new data will be discarded. If the UART is in
use, this can be avoided by the host side honoring CTS flow control.
If the SPI is the serial port, no hardware flow control is available. It is the user's responsibility to ensure
that receive buffer is not overflowed. One reliable strategy is to wait for a TX_STATUS response after each
frame sent to ensure that the module has had time to process it.
, and SPI_CLK must be enabled as peripherals. If both ports are enabled then output will
Serial Transmit Buffer
When RF data is received, the data is moved into the serial transmit buffer and sent out the UART or SPI
port. If the serial transmit buffer becomes full and system buffers are also full, then the entire RF data
packet is dropped. Whenever data is received faster than it can be processed and transmitted out the serial
port, there is a potential of dropping data.
XBee-PRO 900HP UART Flow Control
The RTS and CTS module pins can be used to provide RTS and/or CTS flow control. CTS flow control prov ides
an indication to the host to stop sending serial data to the module. RTS flow control allows the host to signal
the module to not send data in the serial transmit buffer out the UART. RTS and CTS flow control are enabled
using the D6 and D7 commands. Please note that serial port flow control is not possible when using the SPI
port.
CTS Flow Control
If CTS flow control is enabled (D7 command), when the serial receive buffer is 17 bytes away from being
full, the module de-asserts CTS
re-asserted after the serial receive buffer has 34 bytes of space. See FT for the buffer size.
RTS Flow Control
If RTS flow control is enabled (D6 command), data in the serial transmit buffer will not be sent out the
DOUT pin as long as RTS
periods of time to avoid filling the serial transmit buffer. If an RF data packet is received, and the serial
transmit buffer does not have enough space for all of the data bytes, the entire RF data packet will be
discarded.
The UART Data Pres e nt In d i ca tor is a useful feature when using RTS flow control. When enabled, the DIO1
line asserts (low asserted) when UART data is queued to be transmitted from the module. See the D1 command in the Command Reference Tables for more information.
Note: If the XBee is sending data out the UART when RTS
up to 5 characters out the UART or SPI port after RTS
(sets it high) to signal to the host device to stop sending serial data. CTS is
is de-asserted (set high). The host device should not de-assert RTS for long
is de-asserted (set high), the XBee could send
is de-asserted.
©2014DigiInternationalInc. 27
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
XBee-PRO 900HP Serial Interface Protocols
The XBee modules support both transparent and API (Application Programming Interface) serial interfaces.
Transparent Operation - UART
When operating in transparent mode, the modules act as a serial line replacement. All UART data received
through the DIN pin is queued up for RF transmission. When RF data is received, the data is sent out
through the serial port. The module configuration parameters are configured using the AT command mode
interface. Please note that transparent operation is not provided when using the SPI.
Data is buffered in the serial receive buffer until one of the following causes the data to be packetized and
transmitted:
•No serial characters are received for the amount of time determined by the RO (Packetization Time-
out) parameter. If RO = 0, packetization begins when a character is received.
•The Command Mode Sequence (GT + CC + GT) is received. Any character buffered in the serial
receive buffer before the sequence is transmitted.
•The maximum number of characters that will fit in an RF packet is received. See the NP parameter.
API Operation
API operation is an alternative to transparent operation. The frame-based API extends the level to which a
host application can interact with the networking capabilities of the module. When in API mode, all data
entering and leaving the module is contained in frames that define operations or events within the module.
Transmit Data Frames (received through the serial port) include:
•RF Transmit Data Frame
•Command Frame (equivalent to AT commands)
Receive Data Frames (sent out the serial port) include:
•RF-received data frame
•Command response
•Event notifications such as reset, etc.
The API provides alternative means of configuring modules and routing data at the host applic ation l aye r. A
host application can send data frames to the module that contain address and payload information instead
of using command mode to modify addresses. The module will send data frames to the application
containing status packets; as well as source, and payload information from received data packets.
The API operation option facilitates many operations such as the examples cited below:
-> Transmitting data to multiple destinations without entering Command Mode
-> Receive success/failure status of each transmitted RF packet
-> Identify the source address of each received packet
A Comparison of Transparent and API Operation
The following table compares the advantages of transparent and API modes of operation:
Transparent Operation Features
Simple Interface All received serial data is transmitted unless the module is in command mode.
Easy to support It is easier for an application to support transparent operation and command mode
API Operation Features
Transmitting RF data to mu ltiple remotes only requires changing the address in the API frame. This
Easy to manage data
transmissions to multiple
destinations
Received data frames
indicate the sender's
address
Advanced addressing
support
process is much faster than in transparent operation where the app lication must e nter AT command
mode, change the address, exit command mode, and then transmit data.
Each API transmission can return a transmit status frame indicating the success or reason for
failure.
All received RF data API frames indicate the source address.
API transmit and receive frames can expose addressing fields including source and destination
endpoints, cluster ID and profile ID.
©2014DigiInternationalInc. 28
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
Advanced networking
diagnostics
Remote Configuration
As a general rule of thumb, API mode is recommended when a device:
• sends RF data to multiple destinations
• sends remote configuration commands to manage devices in the network
• receives RF data packets from multiple devices, and the application needs to know which device sent
which packet
• must support multiple endpoints, cluster IDs, and/or profile IDs
• uses the Device Profile services.
API mode is required when:
• receiving I/O samples from remote devices
• using SPI for the serial port
If the above conditions do not apply (e.g. a sensor node, router, or a simple application), then transparent
operation might be suitable. It is acceptable to use a mixture of devices running API mode and transparent
mode in a network.
API frames can provide indication of IO samples from remote devices, and node identifica tion
messages.
Set / read configuration commands can be sent to remote devices to configure them as needed
using the API.
XBee-PRO 900HP Modes of Operation
Transparent Operation Features
XBee-PRO 900HP Description of Modes
When not transmitting data, the RF module is in Receive Mode. The module shifts into the other modes of
operation under the following conditions:
•Transmit Mode (Serial data in the serial receive buffer is ready to be packetized)
•Sleep Mode
•Command Mode (Command Mode Sequence is issued, not available when using the SPI port)
Transmit Mode
When serial data is received and is ready for packetization, the RF module will attempt to transmit the data.
The destination address determines which node(s) will receive and send the data.
In the diagram below, route discovery applies only to DigiMesh transmissions. The data will be transmitted
once a route is established. If route discovery fails to establish a route, the packet will be discarded.
©2014DigiInternationalInc. 29
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
Data Discarded
Successful
Transmission
New
Transmission
Route Known?
Route Discovered?
Route Discovery
Transmit Data
Idle Mode
No
Yes
No
Yes
Tra n smitModeSequence
©2014DigiInternationalInc. 30
Loading...