How it Works
Digi
Loading...
PS2CTH
User Manual
178 pgs3.89 Mb0
Table of contents
Loading...

Digi PS2CTH User Manual

Digi International Inc. 11001 Bren Road East Minnetonka, MN 55343 877 912-3444 or 952 912-3444 www.digi.com
XBee®/XBee-PRO® ZB RF Modules
ZigBee RF Modules by Digi International
Models: XBEE S2C, PRO S2C, S2CTH, PS2CTH
Hardware: S2C
Firmware: 401x, 402x, 403x, 404x, 405x
90002002_M 7/23/2014
XBee®/XBee‐PRO®ZBRFModules
© 2014 Digi International Inc. All rights reserved.
Digi, Digi International, the Digi logo, XBee(R) and XBee-PRO(R) are trademarks or registered trademarks of Digi Interna­tional Inc. in the United Sates and other couuntries worldwide. ZigBee(R) is a registered trademark of the ZigBee alliance. All other trademarks mentioned in this document are the property of their respective owners.
Information in this document is subject to change without notice and does not represent a commitment on the part of Digi International.
Digi provides this document “as is,” without warranty of any kind, expressed or implied, including, but not limited to, the implied warranties of fitness or merchantability for a particular purpose. Digi may make improvements and/or changes in this manual or in the product(s) and/or the program(s) described in this manual at any time.
This product could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes may be incorporated in new editions of the publication.
For basic information to help get you started on the XBee/XBee-PRO ZB RF Module, navigate to the Getting Started Guide at
digi.com/support. Enter the keyword 'XBee-PRO ZB' and select the Documentation tab. Under the Documentation tab, you
will find the XBee-PRO ZB RF Module Development Kit Getting Started Guide.
Technical Support: Phone: (866) 765-9885 toll-free U.S.A. & Canada
(801) 765-9885 Worldwide
8:00 am - 5:00 pm [U.S. Mountain Time]
Live Chat: www.digi.com
Online Support:
Email: rf-experts@digi.com
www.digi.com/support/eservice/login.jsp
©2014DigiInternationalInc. 2
XBee®/XBee‐PRO®ZBRFModules
Contents
Overview of the XBee ZigBee RF Module 7
Worldwide Acceptance 7
What’s New in 40xx Firmware 7
Specifications of the XBee ZigBee RF Module 8
Serial Communications Specifications of the XBee ZigBee RF Module 9
UART 9
SPI 9
GPIO Specifications 9
Hardware Specifications for Programmable Variant 10
Mechanical Drawings of the XBee ZigBee RF Module 11
Pin Signals for the XBee ZigBee Surface Mount Mod­ule 12
Pin Signals for the XBee ZigBee Through-hole Module 13
EM357 Pin Mappings 14
Design Notes for the XBee ZigBee RF Module 14
Power Supply Design 14
Recommended Pin Connections 14
Board Layout 15
Module Operation for Programmable Variant 19
XBee Programmable Bootloader 22
Overview 22
Bootloader Software Specifics 22
Bootloader Menu Commands 27
Firmware Updates 28
Output File Configuration 29
XBee ZigBee RF Module Operation 30
XBee ZigBee Serial Communications 30
UART Data Flow 30
XBee ZigBee SPI Communications 30
XBee ZigBee Serial Buffers 31
UART Flow Control 32
XBee ZigBee Break Control 33
Serial Interface Protocols 33
XBee ZigBee Modes of Operation 35
Idle Mode 35
Transmit Mode 35
Receive Mode 36
Command Mode 36
Sleep Mode 37
XBee ZigBee Networks 38
Introduction to ZigBee 38
ZigBee Stack Layers 38
ZigBee Networking Concepts 38
Device Types 38
PAN ID 40
Operating Channel 40
ZigBee Application Layers: In Depth 40
Application Support Sublayer (APS) 40
Application Profiles 40
ZigBee Coordinator Operation 42
Forming a Network 42
Channel Selection 42
PAN ID Selection 42
Security Policy 42
Persistent Data 42
XBee ZigBee Coordinator Startup 42
Permit Joining 43
Resetting the Coordinator 44
Leaving a Network 44
Replacing a Coordinator (Security Disabled Only) 44
Example: Starting a Coordinator 45
Example: Replacing a Coordinator (Security Disabled) 45
ZigBee Router Operation 45
Discovering ZigBee Networks 45
Joining a Network 46
Authentication 46
Persistent Data 46
XBee ZB Router Joining 46
Permit Joining 47
Joining Always Enabled 47
Joining Temporarily Enabled 47
Router Network Connectivity 48
Leaving a Network 49
Network Locator Option 49
Resetting the Router 50
Example: Joining a Network 50
End Device Operation 50
Discovering ZigBee Networks 50
Joining a Network 51
Parent Child Relationship 51
End Device Capacity 51
Authentication 51
Persistent Data 51
Orphan Scans 51
©2014DigiInternationalInc. 3
XBee®/XBee‐PRO®ZBRFModules
Contents
XBee ZigBee End Device Joining 52
Parent Connectivity 52
Resetting the End Device 53
Leaving a Network 53
Example: Joining a Network 53
ZigBee Channel Scanning 53
Managing Multiple ZigBee Networks 54
PAN ID Filtering 54
Pre-configured Security Keys 54
Permit Joining 54
Application Messaging 54
Transmission, Addressing, and Routing 55
Addressing 55
64-bit Device Addresses 55
16-bit Device Addresses 55
Application Layer Addressing 55
Data Transmission 55
Broadcast Transmissions 56
Unicast Transmissions 56
Binding Transmissions 58
Multicast Transmissions 58
Fragmentation 58
Data Transmission Examples 59
RF Packet Routing 61
Link Status Transmission 61
AODV Mesh Routing 62
Many-to-One Routing 64
High/Low Ram Concentrator Mode 65
Source Routing 65
Encrypted Transmissions 68
Maximum RF Payload Size 68
Throughput 69
Latency Timing Specifications 69
ZDO Transmissions 69
ZigBee Device Objects (ZDO) 69
Sending a ZDO Command 70
Receiving ZDO Commands and Responses 70
Transmission Timeouts 72
Unicast Timeout 72
Extended Timeout 72
Transmission Examples 73
XBee ZigBee Security 75
Security Modes 75
ZigBee Security Model 75
Network Layer Security 75
Frame Counter 76
Message Integrity Code 76
Network Layer Encryption and Decryption 76
Network Key Updates 76
APS Layer Security 76
Message integrity Code 77
APS Link Keys 77
APS Layer Encryption and Decryption 77
Network and APS Layer Encryption 77
Trust Center 78
Forming and Joining a Secure Network 78
Implementing Security on the XBee 78
Enabling Security 79
Setting the Network Security Key 79
Setting the APS Trust Center Link Key 79
Enabling APS Encryption 79
Using a Trust Center 79
XBee Security Examples 80
Example 1: Forming a network with security (pre-con­figured link keys) 80
Example 2: Forming a network with security (obtain­ing keys during joining) 80
Network Commissioning and Diagnostics 82
Device Configuration 82
Device Placement 82
Link Testing 82
RSSI Indicators 83
Device Discovery 83
Network Discovery 83
ZDO Discovery 83
Joining Announce 83
Commissioning Pushbutton and Associate LED 83
Commissioning Pushbutton 84
Associate LED 85
Binding 86
Group Table API 88
Managing End Devices 98
End Device Operation 98
Parent Operation 98
End Device Poll Timeouts 99
Packet Buffer Usage 99
Non-Parent Device Operation 99
©2014DigiInternationalInc. 4
XBee®/XBee‐PRO®ZBRFModules
Contents
XBee End Device Configuration 100
Pin Sleep 100
Cyclic Sleep 102
Transmitting RF Data 105
Receiving RF Data 106
I/O Sampling 106
Waking End Devices with the Commissioning Pushbut­ton 106
Parent Verification 106
Rejoining 106
XBee Router/Coordinator Configuration 107
RF Packet Buffering Timeout 107
Child Poll Timeout 107
Transmission Timeout 107
Putting It All Together 108
Short Sleep Periods 108
Extended Sleep Periods 108
Sleep Examples 108
XBee Analog and Digital I/O Lines 110
XBee ZB Through Hole RF Module 110
I/O Configuration 111
I/O Sampling 112
Queried Sampling 113
Periodic I/O Sampling 113
Change Detection Sampling 113
RSSI PWM 114
I/O Examples 114
PWM1 114
XBee ZigBee API Operation 115
API Frame Specifications 115
API Examples 117
API Serial Port Exchanges 118
AT Commands 118
Transmitting and Receiving RF Data 118
Remote AT Commands 118
Source Routing 119
Supporting the API 119
API Frames 119
AT Command 119
AT Command - Queue Parameter Value 120
ZigBee Transmit Request 120
Explicit Addressing ZigBee Command Frame 122
Remote AT Command Request 124
Create Source Route 125
AT Command Response 126
Modem Status 126
ZigBee Transmit Status 127
ZigBee Receive Packet 128
ZigBee Explicit Rx Indicator 129
ZigBee IO Data Sample Rx Indicator 130
XBee Sensor Read Indicator 131
Node Identification Indicator 133
Remote Command Response 134
Extended Modem Status 134
Over-the-Air Firmware Update Status 137
Route Record Indicator 138
Many-to-One Route Request Indicator 139
Sending ZigBee Device Objects (ZDO) Commands with the API 140
Sending ZigBee Cluster Library (ZCL) Commands with the API 142
Sending Public Profile Commands with the API 144
XBee Command Reference Tables 147
XBee ZigBee Module Support 159
XCTU Configuration Tool 159
Customizing XBee ZB Firmware 159
Design Considerations for Digi Drop-In Networking 159
XBee Bootloader 159
Programming XBee Modules 160
Serial Firmware Updates 160
Invoke XBee Bootloader 160
Send Firmware Image 160
Writing Custom Firmware 160
Regulatory Compliance 160
Enabling GPIO 1 and 2 161
Detecting XBee vs. XBee-PRO 161
Special Instructions For Using the JTAG Interface 161
Appendix A: Agency Certifications 163
United States FCC 163
OEM Labeling Requirements 163
FCC Notices 163
FCC-Approved Antennas (2.4 GHz) 164
Europe (ETSI) 167
OEM Labeling Requirements 168
Restrictions 168
Declarations of Conformity 168
Antennas 169
©2014DigiInternationalInc. 5
XBee®/XBee‐PRO®ZBRFModules
Contents
Canada (IC) 169
Transmitters for Detachable Antennas 169
Detachable Antenna 169
Australia (C-Tick) 169
Appendix B:Migrating from XBee ZB to XBee ZB RF
Modules 171
Appendix C:Manufacturing Information 174
Appendix D:Warranty Information 177
Appendix E:Definitions 178
©2014DigiInternationalInc. 6
1.OverviewoftheXBeeZigBeeRFModule
This manual describes the operation of the XBee/XBee-PRO ZB RF module, which consists of ZigBee firmware loaded onto XBee S2C and PRO S2C hardware.
®
XBee
and XBee-PRO® ZB embedded RF modules provide wireless connectivity to end-point devices in ZigBee mesh networks. Utilizing the ZigBee PRO Feature Set, these modules are interoperable with other ZigBee devices, including devices from other vendors. With the XBee, users can have their ZigBee network up-and-running in a matter of minutes without configuration or addtional development.
The XBee/XBee-PRO ZB modules are compatible with other devices that use XBee “ZB” technology. These include Con­nectPortX gateways, XBee and XBee-PRO Adapters, Wall Routers, XBee Sensors, and other products with the “ZB” name.

Worldwide Acceptance

• FCC Approval (USA) Refer to Appendix A for FCC Requirements. Systems that contain XBee/XBee-PRO ZB RF Modules inherit Digi Certifications.
• ISM (Industrial, Scientific & Medical) 2.4 GHz frequency band
• Manufactured under ISO 9001:2000 registered standards
• XBee/XBee-PRO ZB RF Modules are optimized for use in US, Canada, Australia, Europe (XBee only) and Japan (XBee only). Contact Digi for a complete list of agency approvals.

What’s New in 40xx Firmware

• An alternative serial port is available using SPI slave mode operation.
• Six software images (Coordinator AT, Coordinator API, Router AT, Router API, End Device AT, and End Device API) are combined into a single software.
• Fragmentation is now available in both API mode and transparent mode.
• P3 (DOUT), P4 (DIN), D8 (SleepRq), and D9 (On-Sleep
• Both pull-up and pull-down resistors can now be applied to pins configured for inputs.
• 401D - ATVL command added for long version information
• 401E - ATDO command added for configuring device options
• 4020 - ATAS command added for Active Scan
• 4021 - Self addressed Tx Status messages return a status code of 0x23
• ATDO has HIGH_RAM_CONCENTRATOR and NO_ACK_IO_SAMPLING options added.
• 4040 - Binding and Multicasting transmissions are supported.
• AT&X command added to clear binding and group tables.
• Added Tx options 0x04 (indirect addressing) and 0x08 (multicast addressing).
• A 5 second break will reset the XBee. Then it will boot with default baud settings into com­mand mode
• BD range increased from 0-7 to 0-0x0A, and nonstandard baud rates are permitted, but not guaranteed.
• NI, DN, ND string parameters support upper and lower case
• TxOption 0x01 disables retries and route repair. RxOption 0x01 indicates the transmitter dis­abled retries.
• 4050 - FR returns 0x00 modem status code instead of 0x01.
• S2C TH and S2C TH PRO supported.
• DC10 - verbose joining mode option.
• Self addressed fragmentable messages now return the self-addressed Tx Status code (0x23) instead of simply success (0x00).
) are now available for I/O sampling.
©2014DigiInternationalInc. 7
XBee®/XBee‐PRO®ZBRFModules

Specifications of the XBee ZigBee RF Module

SpecificationsoftheXBee®/XBee‐PRO®ZBRFModule
Specification XBee (Surface Mount)
Performance
Indoor/Urban Range Up to 200 ft. (60 m) Up to 300 ft. (90 m) Up to 200 ft. (60 m) Up to 300 ft. (90 m)
Outdoor RF line-of­sight Range
Transmit Power Output (maximum)
RF Data Rate 250,000 bps
Receiver Sensitivity
Power Requirements
Adjustable Power Yes
Supply Voltage
Operating Current (Transmit))
Operating Current (Receive)
Power-down Current
General
Operating Frequency Band
Dimensions 0.866 x 1.33 x 0.120 in (2.199 x 3.4 x 0.305 cm)
Operating Temperature -40 to 85º C (industrial)
Antenna Options RF Pad, PCB Antenna, or U.FL Connector PCB Antenna, U.FL Connector, RPSMA Connector, or Integrated Wire
Networking & Security
Supported Network Topologies
Number of Channels 16 Direct Sequence Channels 15 Direct Sequence Channels 16 Direct Sequence Channels 15 Direct Sequence Channels
Interface Immunity DSSS (Direct Sequence Spread Spectrum)
Channels 11 to 26 11 to 25 11 to 26 11 to 25
Addressing Options PAN ID and Addresses, Cluster IDs and Endpoints (optional)
Interface Options
UART
SPI
Up to 4000 ft. (1200 m) Up to 2 miles (3200 m) Up to 4000 ft. (1200 m) Up to 2 miles (3200 m)
6.3mW (+8dBm), Boost mode
3.1mW (+5dBm), Normal mode Channel 26 max power is +3dBm
-102 dBm, Boost mode
-100 dBm, Normal mode
2.1 - 3.6 V
2.2 - 3.6 V for Programmable Version
45mA (+8 dBm, Boost mode) 33mA (+5 dBm, Normal mode)
31mA (Boost mode) 28mA (Normal mode)
XBee-PRO (Surface Mount)
63mW (+18 dBm)
-101 dBm
2.7 - 3.6 V
100mA @ +3.3 V, +18 dBm
31mA
Point-to-point, Point-to-multipoint, Peer-to-peer, and Mesh
1 Mbps maximum (burst)
5 Mbps maximum (burst)
XBee (Through-hole) XBee-PRO (Through-hole)
6.3mW (+8dBm), Boost mode
3.1mW (+5dBm), Normal mode Channel 26 max power is +3dBm
-102 dBm, Boost mode
-100 dBm, Normal mode
2.1 - 3.6 V
2.2 - 3.6 V for Programmable Version
45mA (+8 dBm, Boost mode) 33mA (+5 dBm, Normal mode)
31mA (Boost mode) 28mA (Normal mode)
o
< 1 A @ 25
ISM 2.4 - 2.5 GHz
C
0.960 x 1.087 in (2.438 x 2.761 cm)
63mW (+18 dBm)
-101 dBm
2.7 - 3.6 V
120mA @ +3.3 V, +18 dBm
31mA
0.960 x 1.297 in (2.438 x 3.294 cm)
©2014DigiInternationalInc. 8
XBee®/XBee‐PRO®ZBRFModules
SpecificationsoftheXBee®/XBee‐PRO®ZBRFModule
Specification XBee (Surface Mount)
Agency Approvals
United States (FCC Part 15.247)
Industry Canada (IC) IC: 1846A-XBS2C IC: 1846A-XBPS2C IC: 1846A-S2CTH IC: 1846A-PS2CTH
FCC/IC Test Transmit Power Output range
Europe (CE) ETSI ETSI
Australia C-Tick
Japan R201WW10215369 Pending
RoHS Compliant
FCC ID: MCQ-XBS2C FCC ID: MCQ-XBPS2C FCC ID: MCQ-S2CTH FCC ID: MCQ-PS2CTH
-26 to +8 dBm 0 to +18 dBm -26 to +8 dBm +1 to +19 dBm
XBee-PRO (Surface Mount)
XBee (Through-hole) XBee-PRO (Through-hole)

Serial Communications Specifications of the XBee ZigBee RF Module

XBee RF modules support both UART (Universal Asynchronous Receiver / Transmitter) and SPI (Serial Peripheral Interface) serial connections.

UART

The SC1 (Serial Communication Port 1) of the Ember 357 is connected to the UART port.
UARTPinAssignments
Specifications Module Pin Number
UART Pins XBee (Surface Mount) XBee (Through-hole)
DOUT 3 2
DIN / CONFIG
/ DIO7 25 12
CTS
/ DIO6 29 16
RTS
More information on UART operation is found in the UART section in Chapter 2.
43
SPI
The SC2 (Serial Communication Port 2) of the Ember 357 is connected to the SPI port.
SPIPinAssignments
Specifications Module Pin Number
SPI Pins XBee (Surface Mount) XBee (Through-hole)
SPI_SCLK 14 18
SPI_SSEL
SPI_MOSI 16 11
SPI_MISO 17 4
For more information on SPI operation, see the SPI section in Chapter 2.
15 17

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 pads are used for purposes such as serial communication.
See GPIO section for more information on configuring and using GPIO ports.
ElectricalSpecificationsforGPIOLines
GPIO Electrical Specification Value
Voltage - Supply 2.1 - 3.6 V
©2014DigiInternationalInc. 9
XBee®/XBee‐PRO®ZBRFModules
ElectricalSpecificationsforGPIOLines
GPIO Electrical Specification Value
Low Schmitt switching threshold 0.42 - 0.5 x VCC
High Schmitt switching threshold 0.62 - 0.8 x VCC
Input current for logic 0 -0.5 A
Input current for logic 1 0.5 A
Input pull-up resistor value 29 k
Input pull-down resistor value 29 k
Output voltage for logic 0 0.18 x VCC (maximum)
Output voltage for logic 1 0.82 x VCC (minimum)
Output source/sink current for pad numbers 3, 4, 5, 10, 12, 14, 15, 16, 17, 25, 26, 28, 29, 30, and 32 on the SMT modules
Output source/sink current for pin numbers 2, 3, 4, 9, 12, 13, 15, 16, 17, and 19 on the TH modules
Output source/sink current for pad numbers 7, 8, 24, 31, and 33 on the SMT modules
Output source/sink current for pin numbers 6, 7, 11, 18, and 20 on the TH modules
Total output current (for GPIO pads) 40 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 8. For example, if the secondary processor is running at 20 MHz and the primary processor is in recieve 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 low pulse time for EM357 +26S
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
4 mA
4 mA
8 mA
8 mA
These numbers add to specifications
mode of operation)
MC9SO8QE32
r2
is the
©2014DigiInternationalInc. 10
XBee®/XBee‐PRO®ZBRFModules

3,1
3,1




7239,(:
%277209,(:
6,'(9,(:

Mechanical Drawings of the XBee ZigBee RF Module

MechanicaldrawingsoftheXBee®/XBee‐PRO®ZBRFModules(antennaoptionsnotshown).Alldimensionsareininches.
.
©2014DigiInternationalInc. 11
XBee®/XBee‐PRO®ZBRFModules

Pin Signals for the XBee ZigBee Surface Mount Module

PinAssignmentsforXBeeSurfaceMountModules
Pin # Name Direction Default State Description
1 GND - - Ground
2 VCC - - Power Supply
3 DOUT / DIO13 Both Output UART Data Out / GPIO
4 DIN / CONFIG
5 DIO12 Both GPIO
6 RESET
7 RSSI PWM / DIO10 Both Output RX Signal Strength Indicator / GPIO
8 PWM1 / DIO11 Both Disabled Pulse Width Modulator / GPIO
9 [reserved] - Disabled Do Not Connect
10 DTR
11 GND - - Ground
12 SPI_ATTN
13 GND - - Ground
14 SPI_CLK / DIO18 Input Input Serial Peripheral Interface Clock / GPIO
15 SPI_SSEL
16 SPI_MOSI / DIO16 Input Input Serial Peripheral Interface Data In / GPIO
17 SPI_MISO / DIO15 Output Output Serial Peripheral Interface Data Out / GPIO
18 [reserved]* - Disabled Do Not Connect
19 [reserved]* - Disabled Do Not Connect
20 [reserved]* - Disabled Do Not Connect
21 [reserved]* - Disabled Do Not Connect
22 GND - - Ground
23 [reserved] - Disabled Do Not Connect
24 DIO4 Both Disabled GPIO
25 CTS
26 ON / SLEEP
27 VREF Input -
28 ASSOCIATE / DIO5 Both Output Associate Indicator / GPIO
29 RTS
30 AD3 / DIO3 Both Disabled Analog Input / GPIO
31 AD2 / DIO2 Both Disabled Analog Input / GPIO
32 AD1 / DIO1 Both Disabled Analog Input / GPIO
33 AD0 / DIO0 Both Input Analog Input / GPIO / Commissioning Button
34 [reserved] - Disabled Do Not Connect
35 GND - - Ground
36 RF Both - RF IO for RF Pad Variant
37 [reserved] - Disabled Do Not Connect
/ SLEEP_RQ / DIO8 Both Input Pin Sleep Control Line / GPIO
/ BOOTMODE / DIO19 Output Output
(Low‐assertedsignalsaredistinguishedwithahorizontallineabovesignalname.)
/ DIO14 Both Input UART Data In / GPIO
Input Module Reset
Serial Peripheral Interface Attention
Do not tie low on reset
/ DIO 17 Input Input Serial Peripheral Interface not Select / GPIO
/ DIO7 Both Output Clear to Send Flow Control / GPIO
/ DIO9 Both Output Module Status Indicator / GPIO
Not used for EM357. 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.
/ DIO6 Both Input Request to Send Flow Control / GPIO
• Signal Direction is specified with respect to the module
• See Design Notes section below for details on pin connections.
• * Refer to the Writing Custom Firmware section for instructions on using these pins if JTAG functions are needed.
©2014DigiInternationalInc. 12
XBee®/XBee‐PRO®ZBRFModules

Pin Signals for the XBee ZigBee Through-hole Module

PinAssignmentsforXBeeThrough‐holeModules
Pin # Name Direction Default State Description
1 VCC - - Power Supply
2 DOUT / DIO13 Both Output UART Data Out
3 DIN / CONFIG
4 DIO12 / SPI_MISO Both Disabled GPIO/ SPI slave out
5 RESET
6 RSSI PWM / PWMO DIO10 Both Output RX signal strength indicator / GPIO
7 PWM1 / DIO11 Both Disabled GPIO
8 [reserved] - - Do Not Connect
9DTR
10 GND - - Ground
11 SPI_MOSI / DIO4 Both Disabled GPIO/ SPI slave in
12 CTS
13 ON_SLEEP
14 VREF - - Not connected
15 ASSOCIATE / DIO5 Both Output Associate Indicator / GPIO
16 RTS
17 AD3 / DIO3 / SPI_SSE
18 AD2 / DIO2 / SPI_CLK Both Disabled Analog Input / GPIO / SPI Clock
19 AD1 / DIO1 / SPI_ATTN
20 AD0 / DIO0 / CB Both Disabled Analog Input / GPIO / Commissioning Button
/ SLEEP_RQ / DIO8 Both Input Pin Sleep Control Line / GPIO
(Low‐assertedsignalsaredistinguishedwithahorizontallineabovesignalname.)
/ DIO14 Both Input UART Data In
Input Input Module Reset
/ DIO7 Both Output Clear-to-Send Flow Control / GPIO
/ DIO9 Both Output Module Status Indicator / GPIO
/ DIO6 Both Input Request to Send Flow Control / GPIO
L Both Disabled Analog Input / GPIO / SPI Slave Select
Both Disabled Analog Input / GPIO / SPI Attention
©2014DigiInternationalInc. 13
XBee®/XBee‐PRO®ZBRFModules

EM357 Pin Mappings

The following table shows how the EM357 pins are used on the XBee.
EM357 Pin # EM357 Pin Name XBee (SMT) Pad # XBee (TH) Pin # Other Usage
12 RST 6 5 Programming
18 PA7 8 7
19 PB3 29 16 Used for UART
20 PB4 25 12 Used for UART
21 PA0 / SC2MOSI 16 11 Used for SPI
22 PA1 / SC2MISO 17 4 Used for SPI
24 PA2 / SC2SCLK 14 18 Used for SPI
25 PA3 / SC2SSEL
26 PA4 / PTI_EN 32 19 OTA packet tracing
27
29 PA6 7 6
30 PB1 / SC1TXD 3 2 Used for UART
31 PB2 / SC1RXD 4 3 Used for UART
33 PC2 / JTDO / SWO 26 13 JTAG (see Writing Custom Firmware section)
34 PC3 / JTDI 28 15 JTAG (see Writing Custom Firmware section)
35 PC4 / JTMS / SWDIO 5 4 JTAG (see Writing Custom Firmware section)
36 PB0 10 9
38 PC1 / ADC3 30 17
41 PB7 / ADC2 31 18
42 PB6 / ADC1 33 20
43 PB5 / ADC0 Temperature sensor on PRO version
PA5 / PTI_DATA /
BOOTMODE
15 17 Used for SPI
12 NA
OTA pacet tracing, force embedded serial bootloader, and SPI attention line
NOTE: Some lines may not go to the external XBee pins in the programmable secondary processor version.

Design Notes for the XBee ZigBee RF Module

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 8.2pF capacitor as near to (pad 2/SMT, pin 1/TH) 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 (pad 2/SMT, pin 1/TH) of the module. The nearest proximity to (pad 2/SMT, pin 1/TH) of the three caps should be in the following order: 8.2pf, 1F followed by 10F.

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.
All unused pins should be left disconnected. All inputs on the radio can be pulled high or low with 30k internal pull-up or pull-down resistors using the PR and PD software commands. No specific treatment is needed for unused outputs.
©2014DigiInternationalInc. 14
XBee®/XBee‐PRO®ZBRFModules
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 pad (pad 28/SMT, pin 15/TH) and the Commissioning pad (pad 33/SMT, pin 20/TH). The Associate LED pad will flash differently depending on the state of the module to the network, and a pushbutton attached to pad 33 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 4mA for pad numbers 3, 4, 5, 10, 12, 14, 15, 16, 17, 25, 26, 28, 29, 30 and 32, and 8mA for pad numbers 7, 8, 24, 31 and 33 on the SMT module. The source and sink capabilities are limited to 4mA for pin numbers 2, 3, 4, 9, 12, 13, 15, 16, 17, and 19, and 8mA for pin numbers 6, 7, 11, 18, and 20 on the TH module.
The VRef pad (pad 27) is only used on the programmable versions of the SMT modules. For the TH modules, a VRef pin (Pin #14) is used. 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. A recommended PCB footprint for the module can be found in Appendix C. 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. With the exception of the RF Pad variant, 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.
Design Notes for PCB Antenna Modules
PCB Antenna modules should not have any ground planes or metal objects above or below the antenna. For best results, the module should not be placed in a metal enclosure, which may greatly reduce the range. The module should be placed at the edge of the PCB on which it is mounted. The ground, power and signal planes should be vacant immediately below the antenna section. The drawings on the following pages illustrate important recommendations when designing with PCB antenna modules. It should be noted that for optimal performance, this module should not be mounted on the RF Pad footprint described in the next section because the footprint requires a ground plane within the PCB Antenna keep out area.
©2014DigiInternationalInc. 15
XBee®/XBee‐PRO®ZBRFModules
SMT Keepout Area
©2014DigiInternationalInc. 16
XBee®/XBee‐PRO®ZBRFModules
TH Keepout Area
©2014DigiInternationalInc. 17
XBee®/XBee‐PRO®ZBRFModules
Design Notes for SMT RF Pad Modules
The RF Pad is a soldered antenna connection. The RF signal travels from pin 36 on the module to the antenna through an RF trace transmission line on the PCB. Please note that any additional components between the module and antenna will violate modular certification. The RF trace should have a controlled impedance of 50 ohms. We recommend using a microstrip trace, although coplanar waveguide may also be used if more isolation is needed. Microstrip generally requires less area on the PCB than coplanar waveguide. Stripline is not recommended because sending the signal to different PCB layers can introduce matching and performance problems.
It is essential to follow good design practices when implementing the RF trace on a PCB. The following figures show a layout example of a host PCB that connects an RF Pad module to a right angle, through hole RPSMA jack. The top two layers of the PCB have a controlled thickness dielectric material in between. The second layer has a ground plane which runs underneath the entire RF Pad area. This ground plane is a distance d, the thickness of the dielectric, below the top layer. The top layer has an RF trace running from pin 36 of the module to the RF pin of the RPSMA connector. The RF trace's width determines the impedance of the transmission line with relation to the ground plane. Many online tools can estimate this value, although the PCB manufacturer should be consulted for the exact width. Assuming d=0.025", and that the dielectric has a relative permittivity of 4.4, the width in this example will be approximately 0.045" for a 50 ohm trace. This trace width is a good fit with the module footprint's 0.060" pad width. Using a trace wider than the pad width is not recommended, and using a very narrow trace (under 0.010") can cause unwanted RF loss. The length of the trace is minimized by placing the RPSMA jack close to the module. All of the grounds on the jack and the module are connected to the ground planes directly or through closely placed vias. Any ground fill on the top layer should be spaced at least twice the distance d (in this case, at least 0.050") from the microstrip to minimize their interaction.
Implementing these design suggestions will help ensure that the RF Pad module performs to its specifications.
PCBLayer1ofRFLayoutExample
©2014DigiInternationalInc. 18
XBee®/XBee‐PRO®ZBRFModules
PCBLayer2ofRFLayoutExample

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 EM357 or the MC9SO8QE micro (see Block Diagram for details). The EM357 by default has control of certain lines. These lines can be released by the EM357 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 VREF pin (27/SMT, 14/TH) 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 9/SMT, Pin 8/TH).
©2014DigiInternationalInc. 19
XBee®/XBee‐PRO®ZBRFModules
©2014DigiInternationalInc. 20
XBee®/XBee‐PRO®ZBRFModules
©2014DigiInternationalInc. 21
XBee®/XBee‐PRO®ZBRFModules

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 over­the-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.
©2014DigiInternationalInc. 22
XBee®/XBee‐PRO®ZBRFModules
©2014DigiInternationalInc. 23
XBee®/XBee‐PRO®ZBRFModules
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 EM357 allowing for direct communication with the EM357. 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.
©2014DigiInternationalInc. 25
XBee®/XBee‐PRO®ZBRFModules
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. 26
XBee®/XBee‐PRO®ZBRFModules
};
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"
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 */
The bootloader provides a "bypass" mode of operation that essentially connects the SCI1 serial communications peripheral of the freescale mcu to the EM357's serial Uart channel. This allows direct communication to the EM357 radio for the purpose of firmware and radio configuration changes. Once in bypass mode, the XCTU utility can change modem configuration and/or update EM357 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 EM357 Radio. 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 the EM357
©2014DigiInternationalInc. 27
XBee®/XBee‐PRO®ZBRFModules
Radio. The EM357 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 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 EM357 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. The XBee module sending the file OTA (Host module) should be set up with a series 2 Xbee module with transparent mode firmware.
b. The XBee Programmable module receiving the update (remote module) is configured with API firmware.
c. 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)
d.Enter 3 pluses "+++" to place the EM357 in command mode. (or XCTU’s “Modem Configuration” tab can be used to set the correct parameters)
e. 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 hexa­decimal 64 bit address of the target module).
f. Hit Enter and the bootloader command menu will be displayed from the remote module. (Note that the option "B" doesn't exist for OTA)
g. Hit the "F" key to cause the remote module to request the new firmware file over-the-air.
h. 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 con­clusion of a successful transfer, the bootloader will jump to the newly loaded application.
©2014DigiInternationalInc. 28
XBee®/XBee‐PRO®ZBRFModules

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 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. 29
2.XBeeZigBeeRFModuleOperation
DIN (data in)
DIN (data in)
DOUT (data out )
DOUT (data out)

XBee ZigBee 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, which is a synchronous interface to be described later.
Two Wire serial Interface (TWI) is also available, but not supported by Digi. For information on the TWI, see the EM357 specification.

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.
SystemDataFlowDiagraminaUART‐interfacedenvironment
(Low‐assertedsignalsdistinguishedwithhorizontallineoversignalname.)
Serial Data
Data enters the module UART through the DIN (pin 4) 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.
UARTdatapacket0x1F(decimalnumberʺ31ʺ)astransmittedthroughtheRFmodule
ExampleDataFormatis8‐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 ZigBee 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
©2014DigiInternationalInc. 30
XBee®/XBee‐PRO®ZBRFModules
•SPI_SSEL (Slave Select) - enables serial communication with the slave
The above four pins are standard for SPI. This module also supports an additional pin, which may be configured to alert the SPI master when it has data to send. This pin is called SPI_ATTN (through polling or interrupts), it can know when it needs to receive data from the module. SPI_ATTN whenever it has data to send and it remains asserted until all available data has been shifted out to the SPI master.
In this mode, the following apply:
• Data/Clock rates of up to 5 Mbps are possible
• Data is MSB first
• Frame Format mode 0 is used (see below)
. If the master monitors this pin
asserts
FrameFormatforSPICommunications
SPI Operation
When the slave select (SPI_SSEL) 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_SSEL asserted to enable the transmit serializer to drive data to the output signal SPI_MISO. A rising edge on SPI_SSEL resets the SPI slave shift registers.
If the SPI_SCLK is present, the SPI_MISO line is always driven whether with or without the SPI_SSEL driven. This is a known issue with the Ember EM357 chip, and makes additional hardware necessary if multiple slaves are using the same bus as the XBee.
If the input buffer is empty, the SPI serializer transmits a busy token (0xFF). Otherwise, all transactions on the SPI port use API operation. See Chapter 9 - API Operation for more information.
The SPI slave controller must guarantee that there is time to move new transmit data from the transmit buffer into the hardware serializer. To provide sufficient time, the SPI slave controller inserts a byte of padding at the start of every new string of transmit data. Whenever the transmit buffer is empty and data is placed into the transmit buffer, the SPI hardware inserts a byte of padding onto the front of the transmission as if this byte were placed there by software.
Serial Port Selection
In the default configuration the UART and SPI ports will both be configured for serial port operation.
If DOUT is held low during boot, then only SPI will be used. If both interfaces are configured, serial data will go out the UART until the SPI_SSEL the SPI interface.
If only the UART is enabled, then only the UART will be used, and SPI_SSEL 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.
signal is asserted. Thereafter, all serial communications will operate on
will be ignored. If only the SPI
pin has to be
line

XBee ZigBee Serial Buffers

The XBee modules maintain small buffers to collect received serial and RF data, which is illustrated in the figure below. The serial receive buffer collects incoming serial characters and holds them until they can be processed.
©2014DigiInternationalInc. 31
Loading...
+ 148 hidden pages
Buy Points How it Works FAQ Contact Us Questions and Suggestions Privacy Policy Cookie Policy Terms of Use