Digi XB900HP 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_B
August 30, 2012
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
© 2012 Digi International, Inc. All rights reserved
Nopartofthecontentsofthismanualmaybetransmittedorreproducedinany
formorbyanymeanswithoutthewrittenpermissionofDigiInternational,Inc.
XBee‐PRO®isaregisteredtrademarkofDigiInternational,Inc.
Technical Support: Phone: (866) 765-9885 toll-free U.S.A. & Canada
Online Support: http://www.digi.com/support/eservice/login.jsp
Email: rf-experts@digi.com
(801) 765-9885 Worldwide
8:00 am - 5:00 pm [U.S. Mountain Time]
©2012DigiInternational,Inc. 2
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
Contents
1. Preface: How to use this manual 5
2. RF Module Hardware 6
XBee-PRO S3B Hardware Description 6
Worldwide Acceptance 6
Specifications 7
Serial Communications Specifications 8
UART 8
SPI 8
GPIO Specifications 8
Hardware Specs for Programmable Variant 8
Mechanical Drawings 10
Pin Signals 11
Design Notes 11
Power Supply Design 11
Recommended Pin Connections 11
Board Layout 12
Module Operation for Programmable Variant 12
XBee Programmable Bootloader 14
Overview 14
Bootloader Software Specifics 14
Bootloader Menu Commands 18
Firmware Updates 19
Output File Configuration 19
3. RF Module Operation 21
Basic Operational Design 21
Serial Communications 21
UART Data Flow 21
SPI Communications 22
SPI Operation 23
Configuration 24
Data Format 25
SPI Parameters 25
Serial Buffers 26
UART Flow Control 26
Serial Interface Protocols 27
Modes of Operation 28
Description of Modes 28
Transmit Mode 28
Receive Mode 30
Command Mode 30
Sleep Mode 31
4. Networking Methods 32
MAC/PHY Basics 32
Related parameters: CM, HP, ID, PL, RR, MT 32
Addressing Basics 32
Related parameters: SH, SL, DH, DL, TO 32
Point to Point/Multipoint (P2MP) 33
Throughput 33
Repeater/Directed Broadcast 33
Related parameters: CE, NH, NN, BH 33
DigiMesh Networking 34
Related Command: MR 34
DigiMesh Feature Set 34
Data Transmission and Routing 34
Transmission Timeouts 35
5. Sleep Mode 37
Sleep Modes 37
Normal Mode (SM=0) 37
Asynchronous Pin Sleep Mode (SM=1) 37
Asynchronous Cyclic Sleep Mode (SM=4) 37
Asynchronous Cyclic Sleep with Pin Wake Up Mode
(SM=5) 38
Synchronous Sleep Support Mode (SM=7) 38
Synchronous Cyclic Sleep Mode (SM=8) 38
Asynchronous Sleep Operation 38
Wake Timer 38
Indirect Messaging and Polling (P2MP Packets
Only) 39
Indirect Messaging 39
Polling 39
Synchronous Sleep Operation (DigiMesh networks only) 39
Operation 39
Becoming a Sleep Coordinator 42
Configuration 43
Diagnostics 45
6. Command Reference Tables 46
7. API Operation 57
API Frame Format 57
API Serial Exchanges 59
AT Commands 59
Transmitting and Receiving RF Data 59
Remote AT Commands 59
Supporting the API 60
Frame Descriptions 60
AT Command 60
AT Command - Queue Parameter Value 61
©2012DigiInternaitonal,Inc. 3
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
Contents
TX Request 61
Explicit TX Request 62
Remote AT Command Request 64
AT Command Response 65
Modem Status 65
Transmit Status 66
Route Information Packet 66
Aggregate Addressing Update 68
RX Indicator 69
Explicit Rx Indicator 70
Node Identification Indicator 70
Remote Command Response 72
8. Advanced Application Features 73
Remote Configuration Commands 73
Sending a Remote Command 73
Applying Changes on Remote Devices 73
Remote Command Responses 73
Network Commissioning and Diagnostics 73
Device Configuration 73
Network Link Establishment and Maintenance 73
Device Placement 74
Device Discovery 75
Link Reliability 75
Commissioning Pushbutton and Associate LED 78
I/O Line Monitoring 80
I/O Samples 80
Queried Sampling 80
Periodic I/O Sampling 82
Digital I/O Change Detection 82
General Purpose Flash Memory 82
Accessing General Purpose Flash Memory 82
Over-the-Air Firmware Upgrades 88
Distributing the New Application 89
Verifying the New Application 89
Installing the Application 89
Things to Remember 90
Appendix A: XSC Firmware 91
Key Features 92
Worldwide Acceptance 92
Specifications 93
Pin Signals 93
Electrical Characteristics 95
Timing Specifications 95
Mechanical Drawings 96
RF Module Operation 97
Serial Communications 97
UART-Interfaced Data Flow 97
Serial Data 97
Flow Control 98
Modes of Operation 99
Idle Mode 99
Transmit Mode 99
Sleep Mode 101
Command Mode 103
RF Module Configuration 105
XBee Programming Examples 105
AT Commands 105
Binary Commands 106
Command Reference Table 106
Command Descriptions 107
RF Communication Modes 124
Addressing 125
Address Recognition 126
Basic Communications 126
Streaming Mode (Default) 126
Repeater Mode 127
Acknowledged Communications 130
Acknowledged Mode 130
Appendix B: Agency Certifications for S3B Hard-
ware 133
FCC (United States) Certification 133
Labeling Requirements 133
FCC Notices 133
Limited Modular Approval 134
FCC-approved Antennas 134
IC (Industry Canada) Certification 134
Appendix C: Agency Certifications for legacy S3/
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
Appendix D: Additional Information 144
©2012DigiInternaitonal,Inc. 4
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 superior 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 which need to be
9XStream compatible. Customers which do not require this compatibility should not use the 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 Num-
bers
XBP09-XC… MCQ-XBEEXSC S3 XSC XSC
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
FCC ID
MCQ-XBPS3B S3B XSC XSC
MCQ-XB900HP S3B XSC XSC / 900HP
Hardware Plat-
form
Pre-installed
Firmware
Firmware avail-
able
Notes
S3B parts of revision
*** and earlier only
accept XSC firmware
and use an FCC ID of
MCQ-XBPS3B.
S3B parts greater
than revision ***
accept both XSC and
900HP firmware and
use an FCC ID of
MCQ-XB900HP.
©2012DigiInternational,Inc. 5
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
1.RFModuleHardware
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 Set, these modules are interoperable with other devices. With the XBee, users can have their 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) - Refe r to A pp e n di x B f o r F C C R e q ui r e me n t s.
Systems that include XBee-PRO Modules inherit Digi’s FCC Certification
ISM (Industrial, Scientific & Medical) frequency band
Manufactured under ISO 9001:2000 registered standards
XBee-PRO® (900 MHz) RF Modules are approved for use in US and Canada.
RoHS compliant
©2012DigiInternational,Inc. 6
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
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 3.0 to 3.6 VDC
Transmit Current 215mA typical, (290mA max)
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
United States (FCC Part
15.247)
Industry Canada (IC) 1846A-XB900HP
Australia C-Tick
Brazil Pending
-101 dBm, high data rate, -110 dBm, low data rate
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, Reverse-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)
902 to 928 MHz (software selectable channels)
9600-230400 baud
connector
64 channels available
MCQ-XB900HP
©2012DigiInternational,Inc. 7
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
* To determine your range, perform a range test under your operating conditions.
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
More information on UART operation is found in the UART section in Chapter 2.
SPI
SPIPinAssignments
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
3
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 3.0- 3.6 V
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
Output source current 6 mA
Output sink current for 6 mA
Total output current (for GPIO pins) 48 mA
Hardware Specs 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
©2012DigiInternational,Inc. 8
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
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
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
These numbers add to specifications
(Add to RX, TX, and sleep currents depending on
mode of operation)
MC9SO8QE32
r2
is the
©2012DigiInternational,Inc. 9
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
Mechanical Drawings
MechanicaldrawingsoftheXBee‐PRO900HPRFModules(antennaoptionsnotshown).Alldimensionsareininches.
.
©2012DigiInternational,Inc. 10
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
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 Input
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 module. 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.
Design Notes
The XBee modules do not specifically require any external circuitry or specific connections for proper
operation. However, there are some general design guidelines that are recommended for help in
troubleshooting and building a robust design.
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 250mV 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.
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.
©2012DigiInternational,Inc. 11
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 port 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.
Board Layout
XBee modules are designed to be self sufficient and have minimal sensitivity to nearby processors, crystals 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 elements radiate perpendicular to the direction
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 tall electrolytic
capacitors.
Module Operation for Programmable Variant
The modules with the programmable option have a secondary 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).
©2012DigiInternational,Inc. 12
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
GND
A
5
4
G
E
12
9
ECO
PART NO.
B
14
2
13
11
SHEET
REV
TITLE
DATE:
1
ENGINEER:
APPROVALS:
REV.
DATE
12
10
17
11
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
1
7
6
5
4
2
8
3 9
DO NOT SCALE DRAWING
J
H
10
Digi I nternational I nc.
All rights reserved
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/SPSCK
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/PTC 5
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
AD4/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 determine
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
1 OF 1
S3B RADIO
©2012DigiInternational,Inc. 13
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
XBee 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.
To 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 cleared 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.
©2012DigiInternational,Inc. 14
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
©2012DigiInternational,Inc. 15
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 directly to the internal microcontroller allowing for direct communication 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 located 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 vector.
The version string pointer and reset vector are used to determine if the application is valid.
©2012DigiInternational,Inc. 16
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 */
©2012DigiInternational,Inc. 17
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.
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 to 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 represents 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-2B0-023_064" will take
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 microcontroller. 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
©2012DigiInternational,Inc. 18
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.
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 parity, 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
©2012DigiInternational,Inc. 19
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
with the 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.
©2012DigiInternational,Inc. 20
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
DIN (data in)
DIN (data in)
DOUT (data out )
DOUT (data out)
2.RFModuleOperation
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 process commands from remote radios (see Remote AT Commands
section).
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.
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.)
©2012DigiInternational,Inc. 21
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 significant 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.
SPI Communications
The XBee modules support SPI communications in slave mode. Slave mode receives 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 queued to send. The XBee mod-
FrameFormatforSPICommunications
©2012DigiInternational,Inc. 22
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
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.
SPI Signals
The official specification for SPI includes the four signals SPI_MISO, SPI_MOSI, SPI_CLK, and SPI_SSEL.
Using only these four signals, the master cannot know when the slave needs to send and the SPI slave 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 AT D4
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
©2012DigiInternational,Inc. 23
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
Clk ___||||||||||||||||||||||||||||||||||||||||||||||||||______________________
MOSI XXXVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVIIIIIIIIIIIIIIIXXXXXXXXXXX
MISO XXXIIIIIIIIIIIIIIIIIIIIIIIIIIIIVVVVVVVVVVVVVVVVVVVVVVVVVVIIIIIXXXXXXXX
SSEL
ATTN
In the above (character oriented) timing diagram the notations mean the following:
___ indicates a low voltage signal
----- indicates a high voltage signal
||| indicates an oscillating clock
XXX indicates don't care data that will not be processed
VVV indicates valid data that should be processed
IIIII indicates invalid data that should be discarded
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 so that it can control pin sleep, whether or not data needs to be transmitted, then
sharing the pin may be a good option in order to make the SLEEP_REQUEST pin available 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
is configured as a peripheral,
rather than by SLEEP_REQUEST. Asserting SPI_SSEL by driving it low
by driving it high puts the radio to sleep.
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.
If only the UART is enabled, then only the UART will be used, and SPI_SSEL
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.
will be ignored. If only the SPI is
©2012DigiInternational,Inc. 24
signal is asserted.
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
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 recovered to UART 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 the 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 this to determine that the SPI port has been configured
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, then 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 falling 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
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.
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.
©2012DigiInternational,Inc. 25
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
Serial Buffers
To enable the UART port, DIN and DOUT must be configured as peripherals. 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.
UART Flow Control
The RTS and CTS module pins can be used to provide RTS and/or CTS flow control. CTS flow control provides
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 Present Indicator 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.
©2012DigiInternational,Inc. 26
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
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 application layer. 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 multiple 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 application must enter 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.
©2012DigiInternational,Inc. 27
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.
Modes of Operation
Transparent Operation Features
API frames can provide indication of IO samples from remote devices, and node identification
messages.
Set / read configuration commands can be sent to remote devices to configure them as needed
using the API.
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.
©2012DigiInternational,Inc. 28
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 s mitModeSequence
©2012DigiInternational,Inc. 29
XBee‐PRO®900HP/XBee‐PRO®XSCRFModules
Example: ATDL 1F<CR>
“AT”
Prex
ASCII
Command
Space
(optional)
Parameter
(optional, HEX)
Carriage
Return
When DigiMesh data is transmitted from one node to another, a network-level acknowledgement is
transmitted back across the established route to the source node. This acknowledgement packet indicates to
the source node that the data packet was received by the destination node. If a network acknowledgement is
not received, the source node will re-transmit the data.
See Data Transmission and Routing in chapter 4 for more information.
Receive Mode
If a valid RF packet is received, the data is transferred to the serial transmit buffer. This is the default mode
for the XBee radio.
Command Mode
To modify or read RF Module parameters, the module must first enter into Command Mode - a state in which
incoming serial characters are interpreted as commands. The API Mode section in Chapter 7 describes an
alternate means for configuring modules which is available with the SPI, as well as over the UART with code.
AT Command Mode
To Enter AT Command Mode:
Send the 3-character command sequence “+++” and observe guard times before and after the command characters. [Refer to the “Default AT Command Mode Sequence” below.]
Default AT Command Mode Sequence (for transition to Command Mode):
•No characters sent for one second [GT (Guard Times) parameter = 0x3E8]
•Input three plus characters (“+++”) within one second [CC (Command Sequence Character) parame-
ter = 0x2B.]
•No characters sent for one second [GT (Guard Times) parameter = 0x3E8]
Once the AT command mode sequence has been issued, the module sends an "OK\r" out the UART pin. The
"OK\r" characters can be delayed if the module has not finished transmitting received serial data.
When command mode has been entered, the command mode timer is started (CT command), and the
module is able to receive AT commands on the UART port.
All of the parameter values in the sequence can be modified to reflect user preferences.
NOTE: Failure to enter AT Command Mode is most commonly due to baud rate mismatch. By default,
the BD (Baud Rate) parameter = 3 (9600 bps).
To Send AT Commands:
Send AT commands and parameters using the syntax shown below.
SyntaxforsendingATCommands
To read a parameter value stored in the RF module’s register, omit the parameter field.
The preceding example would change the RF module Destination Address (Low) to “0x1F”. To store the new
value to non-volatile (long term) memory, send the WR (Write) command. This allows modified parameter
values to persist in the module’s registry after a reset. Otherwise, parameters are restored to previously
saved values after the module is reset.
©2012DigiInternational,Inc. 30
Loading...