ZigBee-2006 Residential Stack Protocol

ZigBee-2006 Residential Stack Protocol
AN1232
Microchip ZigBee-2006 Residential Stack Protocol
Author:
Derrick P. Lattibeaudiere
Microchip Technology Inc.
INTRODUCTION
The ZigBee™ protocol is a wireless network protocol
specifically designed for low data rate sensors and control networks. There are a number of applications that
can benefit from the ZigBee protocol including, but not
limited to: building automation networks, home security
systems, industrial control networks, remote metering
and PC peripherals.
When compared against other wireless protocols, the
ZigBee wireless protocol offers low complexity,
reduced resource requirements and, most importantly,
a standard set of specifications. It also offers three frequency bands of operation along with a number of
network configurations and optional security capability.
This application note is specifically designed to assist
designers who are interested in adopting the ZigBee
protocol in their applications. The Microchip Stack for
the ZigBee Protocol provided in this application note
can be used to quickly build applications. To illustrate
the usage of the Stack, several working demo applications are included. Use these demo applications as a
reference or simply modify and adopt them as required.
Note:
Please note that companies wishing to
distribute a product that utilizes the Microchip Stack for the ZigBee Protocol must
become a member of the ZigBee Alliance.
For further information regarding frequently asked questions about ZigBee,
please refer to http://www.zigbee.org/en/
about/faq.asp, and specifically to document
053594r03_ZQG_ZigBee_Certification
FAQ.
Commonly asked questions about the Microchip Stack
and its usage, along with their answers, are provided at
the end of this document in “Answers to Frequently
Asked Questions (FAQs)”.
ASSUMPTION
This document assumes that the reader is familiar with
the C programming language. It also uses terminology
from the ZigBee protocol and IEEE 802.15.4-2003
specifications and provides a brief overview of the
ZigBee protocol specification. Readers are advised to
read the ZigBee protocol and IEEE 802.15.4-2003
specifications in detail. For additional technical information on the IEEE 802.15.4™ specifications, please
refer to http://standards.ieee.org/catalog/. For additional technical information on the ZigBee specifications, please refer to www.zigbee.org.
FEATURES
The Microchip Stack for the ZigBee Protocol is
designed to evolve with the ZigBee wireless protocol
specification. At the time of publication, the current
applicable ZigBee protocol specification version is
ZigBee-2006 r13. This document applies to Microchip
Stack releases v2.0-2.6 and greater, but not to ZigBee
PRO, which will be addressed in a separate application
note.
The Microchip Stack offers the following features:
• A certified ZigBee-2006 compliant platform
• Support for the 2.4 GHz frequency band
• Support for all ZigBee protocol device types
(Coordinators, Routers and End devices)
• Implements nonvolatile storage for the Group
table and other critical network parameters such
as neighbor and routing tables
• Portable across many of the PIC18 and PIC24
families of microcontrollers
• RTOS and application independent
• Out-of-box support for Microchip MPLAB C Compiler for PIC18 MCUs (formerly MPLAB C18 C
Compiler) and MPLAB C Compiler for PIC24
MCUs and dsPIC® DSCs (formerly MPLAB C30 C
Compiler)
• Support for Multicast Addressing
• Support for the End Device Rejoin mechanism
For the latest features and enhancements over previous releases, refer to the Readme file distributed with
the source code for the Microchip Stack for the ZigBee
Protocol.
© 2008 Microchip Technology Inc.
DS01232A-page 1
AN1232
CONSIDERATIONS
ZigBee PROTOCOL OVERVIEW
Version 2.0-2.6 of the Microchip Stack for the ZigBee
Protocol is the second version to be granted the status
of ZigBee Compliant Platform (ZCP). For information
on the ZCP status of the first version, v1.0-3.8, please
refer to AN965, “Microchip Stack for the ZigBee™
Protocol”.
The ZigBee protocol is a standard wireless network
protocol designed for low data rate control networks. It
is layered on top of the IEEE 802.15.4 specification and
provides a standard methodology for performing networking functions, such as network formation, device
address assignments, routing, messaging and device
discovery.
LIMITATIONS
The ZigBee protocol specification leaves many higher
level decisions up to the developer. As such, the
Microchip Stack provides no explicit support for some
functions:
• Beacon networks are not supported in this version
of the ZigBee protocol stack
• Network addresses of nodes that have left the
network cannot be reassigned
• Fragmentation is not supported
• Frequency agility is not supported
• Alternate PAN coordinator capability is not supported in ZigBee protocol networks. Only a single
ZigBee protocol coordinator is permitted
FEATURES NEW TO ZigBee-2006
As implemented in version v2.0-2.6 of the Microchip
ZigBee protocol Stack, below is a list of the primary new
features:
• Supports Multicast Addressing – allows for the
definition of a group of devices, while simultaneously allowing individual devices to be members
of multiple groups. A single group ID is then used
to address multiple devices simultaneously
• Supports Source Binding – allows the end devices
to individually maintain their own binding table,
and relieves the coordinator of this responsibility.
• Supports Device Rejoining – Allows an end
device to be efficiently repositioned within a given
network configuration by allowing to it to request a
new parent.
• Support for KVP message scheme has been
eliminated, and only the MSG format remains.
IEEE 802.15.4-2003
The ZigBee protocol uses the IEEE 802.15.4-2003
specification as its Medium Access Layer (MAC) and
Physical Layer (PHY). The IEEE 802.15.4 defines
three frequency bands of operations: 2.4 GHz, 915
MHz and 868 MHz. Each frequency band offers a fixed
number of channels, i.e., the 2.4 GHz frequency band
offers 16 channels (channels 11-26), 915 MHz offers
10 channels (channels 1-10) and 868 MHz offers
1 channel (channel 0).
The bit rate of the protocol depends on the operational
frequency. The 2.4 GHz band provides up to 250 kbps,
915 MHz provides up to 40 kbps and 868 MHz provides
a data rate up to 20 kbps. The actual data throughput
will be less than the maximum specified bit rate due to
the packet overhead and processing delays.
The maximum length of an IEEE 802.15.4-2003 MAC
packet is 127 bytes, including a 16-bit CRC value. The
16-bit CRC value verifies the frame integrity. In addition,
IEEE 802.15.4-2003 optionally uses an Acknowledged
data transfer mechanism. With this method, all frames
with a special acknowledgement request flag set are
Acknowledged by its receiver. This ensures that a frame
is in fact delivered. If a frame is transmitted with the
acknowledgement request flag set and the Acknowledgement is not received within a certain time-out
period, the transmitter will retry the transmission for a
fixed number of times before declaring an error. It is
important to note that the reception of an Acknowledgement simply indicates that a frame was properly
received by the MAC layer. It does not, however, indicate
that the frame was processed correctly. It is possible that
the MAC layer of the receiving node received and
Acknowledged a frame correctly, but due to the lack of
processing resources, a frame might be discarded by
upper layers. As a result, the upper layers may require
additional Acknowledgement response.
DEVICE TYPES
IEEE 802.15.4-2003 defines two types of devices.
These device types are shown in Table 1. Listed in
Table 2 are the three types of ZigBee protocol devices
as they relate to the IEEE device types.
DS01232A-page 2
© 2008 Microchip Technology Inc.
AN1232
TABLE 1:
IEEE 802.15.4™ DEVICE TYPES
Device Type
Full Function Device (FFD)
Services Offered
Typical Power Source
Typical Receiver
Configuration
Most or All
Mains
On when Idle
Limited
Battery
Off when Idle
Reduced Function Device (RFD)
TABLE 2:
ZigBee™ PROTOCOL DEVICE TYPES
ZigBee Protocol Device
IEEE Device Type
Typical Function
Coordinator
FFD
One per network. Forms the network, allocates network
addresses, allows other devices to join the network
Router
FFD
Optional. Extends the physical range of the network. Allows
more nodes to join the network. May also perform monitoring
and/or control functions.
End
FFD or RFD
Performs monitoring and/or control functions.
NETWORK CONFIGURATIONS
Star Network Configuration
A ZigBee protocol wireless network may assume many
types of configurations. In all network configurations,
there are at least two main components:
A star network configuration (refer to Figure 1) consists
of one ZigBee protocol coordinator node and one or
more end devices. In a star network, all end devices
communicate only with the coordinator. If an end
device needs to transfer data to another end device, it
sends its data to the coordinator. The coordinator, in
turn, forwards the data to the intended recipient.
• A coordinator node
• An end device
The ZigBee protocol coordinator is a special variant of a
Full Function Device (FFD) that implements a larger set
of ZigBee protocol services. An end device may be an
FFD, like a Router, or a Reduced Function Device
(RFD). RFD is the smallest and simplest ZigBee protocol
node. It implements only a minimal set of ZigBee protocol services. A third and optional component, the ZigBee
protocol router, is present in some network configurations.
FIGURE 1:
STAR NETWORK CONFIGURATION
Legend
Coordinator
FFD
RFD
Cluster Tree Topology
Another network configuration is a cluster tree topology
(refer to Figure 2). In this configuration, end devices may
join either to the ZigBee protocol coordinator or to the
ZigBee protocol routers. Routers serve two functions.
© 2008 Microchip Technology Inc.
One is to increase the number of nodes that can be on a
network. The other is to extend the physical range of the
network. With the addition of a router, an end device
need not be in radio range of the coordinator. All messages in a cluster tree topology are routed along the
tree.
DS01232A-page 3
AN1232
FIGURE 2:
CLUSTER TREE TOPOLOGY
Legend
Coordinator
Router
FFD
RFD
Mesh Network
A mesh network (refer to Figure 3) is similar to a cluster
tree configuration, except that FFDs can route messages directly to other FFDs instead of following the
FIGURE 3:
tree structure. Messages to RFDs must still go through
the RFD’s parent. The advantages of this topology are
that message latency can be reduced and reliability
robustness to node failures is increased.
MESH NETWORK
Legend
Coordinator
Router
FFD
RFD
The cluster tree and mesh topologies are also known
as multi-hop networks, due to their abilities to route
packets through multiple devices, while the star
topology is a single-hop network. A ZigBee protocol
DS01232A-page 4
network is a multi-access network, meaning that all
nodes in a network have equal access to the medium
of communication.
© 2008 Microchip Technology Inc.
AN1232
ACCESS MECHANISM
There are two types of multi-access mechanisms:
beacon and non-beacon. In a non-beacon enabled network, all nodes in the network are allowed to transmit
at any time if the channel is Idle. In a beacon enabled
network, nodes are allowed to transmit in predefined
time slots only. The coordinator periodically transmits a
superframe identified as a beacon frame, and all nodes
in the network are expected to synchronize to this
frame. Each node is assigned a specific slot in the
superframe during which it is allowed to transmit and
receive its data. A superframe may also contain a common slot during which all nodes compete to access the
channel. The current version of the Microchip Stack
supports only non-beacon networks.
ZigBee PROTOCOL TERMINOLOGY
Below are descriptions of some common ZigBee
protocol terms:
• Application Profiles: Application Profiles enable
the user application code to send commands,
request data and process commands and
requests from other devices on the network in a
well defined and consistent manner. The Application profile is simply the descriptions of the
devices on the network as well as the interface
and messages that are communicated between
devices. There are two types of profiles: Public
and Private profiles. A Public profile is one that is
wholly defined by the ZigBee Alliance. It allows
products that are built upon a particular Public
profile to seamlessly interoperate with each other
because they share the same messaging and
communication mechanism.
A Private profile is defined by an individual company or group of companies, and is intended for
use within a “closed” system, where interoperability is not required. With a private profile, the
emphasis shifts to ‘co-existence’ with other ZigBee networks instead of interoperability and sharing of a common messaging scheme. The
ZigBee Alliance, however, is still responsible for
issuing the Private Profile Identification that is
used within the network.
• Attributes: Each piece of data that can be
passed between devices, such as the state of a
switch (on/off) or a meter reading (100 amps) is
called an attribute. Within a profile, each attribute
is assigned a unique identifier – Attribute ID.
• Clusters: A cluster is a group of attributes. Each
cluster is assigned a unique identifier – Cluster ID.
© 2008 Microchip Technology Inc.
• Endpoints: A given device may be capable of
supporting a number of applets or application
objects. For example a device may simultaneously support a security system composed of
cameras and alarms as well as operate a separate system of lights. Each of the application
objects, in this example a security application
object as well as a light application object, is identified by a unique identifier called an Endpoint. Up
to 240 unique endpoints (application objects) can
be defined per device.
The profile defines the values of the Attribute IDs and
the Cluster IDs, as well as the format of each attribute.
For example, in the Home Control Automation profile,
the cluster OnOffDRC of the Dimmer Remote Control
(DRC) device contains one attribute, OnOff, which
must be an unsigned 8-bit value, with the value 0xFF
meaning “on”, the value 0x00 meaning “off” and the
value 0xF0 meaning “toggle output”.
The profile also describes which clusters are mandatory and which are optional for each device. In addition,
the profile may define some optional ZigBee protocol
services as mandatory.
Different devices communicate via their endpoints and
the clusters they support.
Figure 4 shows graphically how the various terms
relate to each other. The figure shows two devices from
the Home Control Automation profile. Each device has
only one endpoint. The Switch Load Controller (e.g., a
light) has one input cluster on that endpoint. The Switch
Remote Control (e.g., a switch) has one output cluster
and one input cluster on its endpoint. The switch could
also be implemented such that the two clusters are on
separate endpoints. Data flow is at the cluster level.
DS01232A-page 5
AN1232
FIGURE 4:
ZigBee™ PROTOCOL PROFILE ARCHITECTURE
Switch Remote Control
Switch Load Controller
Endpoint 7
Endpoint 15
OnOffSRC
OnOffSRC
OnOff
OnOff
ProgramSRC
Override
Legend
Auto
Attribute
FactoryDefault
Cluster
Endpoint
Device
Description
Communicating Via Messaging
Devices on the network communicate with each other
using messages. If a device knows the network
address of another device that it wishes to communicate with, it sends the message using the destination
devices' network address. This type of message communication is called Direct Addressing. While direct
addressing is simple to understand and use, it comes
with some overhead. Each device is required to first
discover and then maintain a record of addresses of
the destination devices of interest.
FIGURE 5:
SRC ADDR
The ZigBee protocol offers a second means of sending
messages via a mechanism called binding. Whenever
a device supports binding, it maintains a Binding Table
wherein each table entry contains the destination
address and destination endpoint of another device to
which the source device is bounded. Figure 5 is a pictorial representation of the type of information stored in
the Binding Table.
EXAMPLE OF A BINDING TABLE ENTRY
SRC EP
PROFILE
CLUSTERID
DST ADDR
DST EP
Whenever a source device desires to communicate
with a device to which it is bind, it simply creates the
messages without specifying a destination address.
Internal to the Stack and transparent to the application,
the Binding Table is searched, and if a match is found
that contains a destination address and endpoint, then
the destination address is extracted from the table and
appended to the message, before it is transmitted.
This form of communication is called Indirect
Addressing.
DS01232A-page 6
© 2008 Microchip Technology Inc.
AN1232
ZigBee Protocol Message Format
Network Addresses
A ZigBee protocol message consists of up to 127 bytes
in the following fields:
Devices use their extended addresses to communicate
while they are in the process of joining a network. After
a device successfully joins a ZigBee protocol network, it
is assigned a 16-bit network address by its parent from
a pool of pre-defined addresses, which it then uses to
communicate with other devices on the network.
• MAC Header – The MAC header contains the
MAC Frame Control fields, Beacon Sequence
Number (BSN) and addressing information of the
message as it is currently being transmitted. Note
that it may not reflect the actual source or the final
destination of the message if the message is
being routed. The generation and use of this
header is transparent to the application code.
• Network Layer (NWK) Header – This header
contains, along with other information, the actual
source and final destination of the message. The
generation and use of this header is transparent
to the application code.
• Application Support Sub-Layer (APS) Header–
This header includes the Profile ID, Cluster ID and
destination endpoint of the current message. The
generation and use of this header is transparent
to the application code.
• APS Payload – This field contains the ZigBee
protocol frame for the application to process. The
application code is responsible for filling in the
APS Payload.
ZigBee Protocol Frame Format
Each profile specification is responsible for defining the
frame format of each message that the profile supports.
Unicast
In a unicast message, the address of the destination
node is provided in the MAC layer header of the packet.
Only the device who has that address receives the
message. All other devices will filter out messages not
intended for them.
Broadcast
In a broadcast packet, the MAC layer destination
address is 0xFFFF. Any transceiver whose Receiver is
enabled will receive the message. This form of addressing is used when joining a network, discovering routes in
the network and performing other ZigBee protocol discovery functions. ZigBee protocol implements a “passive-acknowledge” of broadcast packets. What is meant
by passive-acknowledge is that when a device originates or retransmits a broadcast packet, it will listen for
all of its known neighbors to retransmit the packet. If all
neighbors have not replicated the message within
nwkPassiveAckTimeout seconds, it will retransmit the
packet until it hears the retransmissions from all of its
known neighbors or the packet times out after
nwkNetworkBroadcastDeliveryTime seconds.
Addressing
Each node on a ZigBee protocol network will have two
addresses: a 64-bit MAC address, and a 16-bit network
address. There are also two forms of message
addressing available.
IEEE Extended Unique Identifiers – EUI-64
Every device that communicates using the ZigBee
protocol must have a globally unique, 64-bit MAC
address. This address is made up of a 24-bit
Organizationally Unique Identifier (OUI) plus 40 bits
assigned by the manufacturer. OUIs must be
purchased from IEEE to ensure global uniqueness.
You may obtain your own OUI number by applying at
the following web address:
https://standards.ieee.org/regauth/oui/forms/
OUT-form.shtml
If your organization already has an OUI for Ethernet
applications, that same OUI may be used for ZigBee
protocol applications. You may not use the Microchip
OUI for production devices.
© 2008 Microchip Technology Inc.
Multicast
An application may choose to designate a collection of
devices and specific endpoints on those devices, to
form a single group. Thereafter, that collection of
devices can be addressed simultaneously using a single group address or Group ID. An example of multicasting might be to group all the lights in a room (a
bedroom for example) into a single multicast group.
Then sending a single ‘on’ message from a switch can
be used to turn on all the lights at once. Multicasting
can be employed as an effective way to reduce the
traffic on a given network.
Multicasting is a new feature for the ZigBee-2006 protocol stack. It is a variant of broadcast addressing,
where the Group ID is used as the destination address
instead of address 0xFFFF at the application level.
In the current implementation of the ZigBee-2006 protocol stack, version v2.0-2.6, up to eight groups per
device can be supported. Users have the option of
changing this limitation at compile time while they are
building their code.
DS01232A-page 7
AN1232
It is important to note that multicasting can be combined with indirect addressing to provide a binding with
a group. In this case the destination address in the bind
table is actually a Group ID address.
FIGURE 6:
Whenever a device supports multicasting, it maintains
a Group Table wherein each table entry contains the
Group ID and a list of destination endpoints to which
received messages are directed when they match the
Group ID. Figure 6 is a pictorial representation of the
type of information is stored the Group Table.
EXAMPLE OF A GROUP TABLE ENTRY
GROUP ID
EPa
Internal to the Stack and transparent to the application,
the Group Table is searched whenever a multicast
message is received, and if a match is found that contains a Group ID, then the message is directed to all
application endpoints found in the Group Table entry.
EPb
••••••••
2.
Data Transfer Mechanism
In a non-beacon enabled network, when a device
wants to send a data frame, it simply waits for the channel to become Idle. Upon detecting an Idle channel
condition, the device may transmit the frame.
If the destination device is an FFD, then its transceiver
is always on, and other devices may transmit to it at any
time. This capability allows for mesh networking. However, if the destination device is an RFD, it may power
down its transceiver when it is idle to conserve power.
The RFD will not be able to receive messages while it
is in this state. This condition is handled by requiring
that all messages to and from the RFD go through the
child RFD’s parent. When the RFD powers up its transceiver, it requests messages from its parent. If the parent has buffered a message for the RFD, it then
forwards that message to the child. This allows the
child RFD to conserve power, but requires that the parent FFD have enough RAM to buffer messages for all
of its children. If the child does not request messages
within a certain time period (macTransactionPersistenceTime), the message will time out, and the parent
will discard it.
Routing
The Microchip Stack has the ability to route messages.
Routing is done automatically by the Stack without any
intervention from the end application. Routing allows
the range of the network to be extended by allowing
end devices beyond radio distance of the ZigBee
protocol coordinator to join the network through a
ZigBee protocol router.
The type of routing desired for a message is indicated
when the message is sent. There are three routing
options available:
1.
3.
EPn
ENABLE – If a discovered mesh route exists,
the message is routed along that route. If a
mesh route has not been determined, the router
can initiate route discovery. When discovery is
complete, the message will be sent along the
calculated route. If the router does not have
route capacity, it will route the message along
the tree.
FORCE – If the router has route capacity, it will
initiate route discovery, even if a route already
exists. When discovery is complete, the message will be sent along the calculated route. If
the router does not have route capacity, it will
route the message along the tree. This option
should be used sparingly, as it generates a great
deal of network traffic. Its primary use is to repair
a broken route.
FORMING AND JOINING A NETWORK
Network Forming
A new ZigBee protocol network is first established by a
ZigBee protocol coordinator. On start-up, a ZigBee protocol coordinator searches for other ZigBee protocol
coordinators operating on its allowed channels. Based
on the channel energy and number of networks found
on each allowed channel, it establishes its own network
and selects a unique 16-bit Personal Area Network
(PAN) ID. Once a new network is established, ZigBee
protocol routers and end devices are allowed to join the
network.
Once a network is formed, it is possible that due to the
physical changes, more than one network may overlap
and a PAN ID conflict may arise. In that situation, a
coordinator may initiate a PAN ID conflict resolution
procedure and one of the coordinators would change
its PAN ID and/or channel. The affected coordinator
would instruct all of its child devices to make the
necessary changes. The current version of the
Microchip Stack does not support PAN ID conflict
resolution.
SUPPRESS – If a discovered mesh route exists,
the message is routed along that route.
Otherwise, the message is routed along the
tree.
DS01232A-page 8
© 2008 Microchip Technology Inc.
AN1232
Network Association
Network Orphaning
A parent-child relationship is formed when a device that
is already a member of a network allows a new device
to join it. In this case, the new device becomes the
child, and old first device becomes the parent. One
way for the new device to join the first device is by using
the ZigBee protocol association procedure.
The child device initiates the association procedure by
performing an active scan of its allowed channels. The
amount of time that a device spends determining the
channel energy and available networks on each channel
is specified by the ScanDuration parameter. Refer to
“ZigBee Protocol Timing” for details on how this
parameter is derived. For the 2.4 GHz frequency band,
the scanning time in seconds is calculated by the
equation:
ZigBee protocol devices store information about other
nodes in the network, including parent and child nodes,
in an area of nonvolatile memory called a Neighbor
Table. On power-up, if a child device determines through
its Neighbor Table that it once was part of a network, it
may execute an orphan notification procedure to locate
its previously associated network. Devices that receive
the orphan notification will check their Neighbor Tables
and see if that device is one of their children. If so, the
parent device will inform the child device of its place in
the network. If orphan notification fails, or the child
device has no parent entry in its Neighbor Table, then it
will try to join the network as a new device. It will generate a list of potential parents and try to join an existing
network at the optimal depth.
EQUATION 1:
Network Rejoin
0.01536 * (2ScanDuration + 1)
For the Microchip Stack, ScanDuration may be
between 0 and 14, giving a scan time of 0.031 seconds
to 4.2 minutes per channel. If ScanDuration is set
to 8 and all 16 channels are specified, a device will
spend over one minute performing each required scan.
ZigBee protocol routers and end devices perform one
scan to determine available networks, but ZigBee protocol coordinators perform two scans, one to sample
channel energy and one to determine existing networks. The specified scan duration needs to balance
the time needed to adequately perform each scan on
the specified channels with the amount of time allocated for system start-up.
Potential parents listening on the channel which is
scanned by the child, respond with a beacon frame.
Beacon frames contain, among other information, data
which indicates if the responding device is accepting
additional device associations.
A collection of the
beacon frame information that is received by the new
device is first stored into its Neighbor Table. At the end
of the scanning process, the Neighbor Table entries are
examined and the “best” potential parent is selected.
The new device then transmits a join request to the
potential parent. If a successful join request confirmation is received from the potential parent, the new
device becomes joined/associated with the first device
in a parent-child relationship. The parent device is
responsible for assigning the child device a unique 16bit network address. Relevant information such as the
child's network address, the parent's network address,
the depth in the network at which the device has joined,
is stored in the both the parent and the child's
nonvolatile Neighbor Table.
© 2008 Microchip Technology Inc.
When an end device loses communication contact with
its parent, or it is asked to leave the network with its
‘rejoin bit’ set, it will automatically initiate a rejoin procedure. Unlike the orphaning procedure, where the child
device attempts to join its old parent, the rejoin procedure commences with an active scan and a new potential parent is picked from the list of beacons that the
child receives. After the child picks a potential parent,
a network level rejoin request is unicast to the potential
parent. After a successful rejoin response is received
from the parent, the child device is now back onto the
network with a new parent and a new network address.
It is important to note that this is an effective way to
reposition a device on the network simply by asking it
to leave and rejoin. Additionally, the rejoin procedure
is initiated and carried out transparently to the application. This is an effective way for end devices to get
back on the network, if it loses communications with its
parent of any reason.
Routers do not automatically initiate rejoins because
they do not have a direct way of determining that their
parents are not on the network, unlike RFD devices,
which poll their parents. Application intervention is
required to in order to have a router rejoin a network.
STACK ARCHITECTURE
The Microchip Stack is written in the C programming
language, and is designed to run on Microchip’s PIC®
microcontrollers. The Microchip Stack can use either
internal Flash program memory, or external Nonvolatile
Memory (NVM) to store a number of persistent stack
parameters across resets of a device. The Designer
has a choice of which type of NVM to use – internal or
external. The current default stack operation is that the
internal Flash program is used in the PICDEM Z Demonstration board, while an external EEPROM is used
on the Explorer 16 platform.
DS01232A-page 9
AN1232
The Microchip Stack is designed to follow the ZigBee
protocol and IEEE 802.15.4-2003 specifications, with
each layer in its own source file. Refer to Figure 7 for a
pictorial representation of the ZigBee stack. Terminology is copied as closely as possible from the specifications. The primitives defined in the two specifications
are used to interface with the Stack through a single
function call, using the parameter list defined for the
FIGURE 7:
primitives in the specifications. Refer to “Interfacing
with the Microchip Stack for the ZigBee Protocol”
for detailed descriptions of typical primitive flow. Refer
to the ZigBee protocol and IEEE 802.15.4 specifications for detailed descriptions of the primitives and their
parameter lists.
ZigBee™ PROTOCOL STACK ARCHITECTURE
Application (APL) Layer
ZDO – ZigBee™ Protocol Device Objects
Application
Object
Endpoint
240
Application
Object
ZDO Public
Interface
Application Framework (AFG)
Device Mgmt.
Security Mgmt.
Binding Mgmt.
NWK Mgmt.
Endpoint 0
Endpoint 1
Endpoint Multiplexing
APSME – SAP
APSME – SAP
APSDE – SAP
APS Message
Management
APS Security
Management
NLDE – SAP
NLME – SAP
NWK – Network Layer
Routing
Management
NWK
Management
ZDO
Mgmt.
Plane
NLME – SAP
SSP –
Security
Service
Provider
SSP Interface
Application Support Sublayer (APS)
NWK Security
Management
MLME – SAP
MCPS – SAP
MAC (IEEE 802.15.4)
PD – SAP
PHY (IEEE 802.15.4)
DS01232A-page 10
PLME – SAP
2.4 GHz
868/915 MHz
© 2008 Microchip Technology Inc.
AN1232
TYPICAL ZigBee PROTOCOL NODE
HARDWARE
To create a typical ZigBee protocol node using the
Microchip Stack, you need, at a minimum, the following
components:
• One Microchip microcontroller with an SPI
interface
• Microchip MFR24J40 RF transceiver with
required external components
• An antenna – may be a PCB trace antenna or
monopole antenna
• External serial EEPROM (optional)
As shown in Figure 8, the microcontroller connects to
the MRF24J40 transceiver via the SPI bus and a few discrete control signals. The microcontroller is the SPI master and the MRF24J40 transceiver acts as a slave. The
TABLE 3:
controller implements the IEEE 802.15.4 Medium
Access Control (MAC) layer and ZigBee protocol layers.
It also contains application-specific logic. It uses the SPI
bus to interact with the RF transceiver.
The Microchip Stack provides a fully integrated driver,
which relieves the main application from managing RF
transceiver functions. The hardware resources required
by the PIC18F/PIC24F microcontroller families to drive
the RF transceiver in the default implementation (provided in the PICDEM Z Demonstration Kit or the
Explorer 16 platform) are listed in Table 3. If you are
using a Microchip reference schematic for a ZigBee protocol node, you may start using the Microchip Stack
without any modifications. If required, you may relocate
some of the non-SPI control signals to other port pins to
suit your application hardware. In this case, you will have
to modify the interface definitions to include the correct
pin assignments.
PIC18F MICROCONTROLLER RESOURCES REQUIRED BY THE ZigBee™
PROTOCOL STACK
PIC18F Resource
PIC24F Resource
Description
MRF24J40
INT0
INT1
Used to accept interrupts from
MRF24J40 transceiver
INT
TMR0
TMR2
Used for symbol timer
RC0
RB2
Chip selection
RC1
RG3
Wake-up pin
WAKE
RESET
–
CS
RC2
RG2
Transceiver Reset
RC3
RF6
SPI SCK
SCK
RC4
RF7
SPI SDI
SDO
RC5
RF8
SPI SDO
SDI
The Microchip reference design for the ZigBee protocol
implements both a PCB trace antenna and a monopole
antenna design. Depending on your choice of antenna,
you will have to remove and solder a few components.
Refer to the “PICDEM™ Z Demonstration Kit User’s
Guide” (DS51524) for more information (see
“References”).
The Microchip RF transceiver is a 3.3V device.
Depending on the requirements, the designer may
either use mains or a battery power supply. Typically,
ZigBee protocol coordinators and routers would operate on mains power supply and end devices would
operate on a battery. When using a battery power supply, care must be taken to operate the transceiver
within the specified voltage range.
© 2008 Microchip Technology Inc.
DS01232A-page 11
AN1232
FIGURE 8:
TYPICAL ZigBee™ PROTOCOL NODE HARDWARE (CONTROL SIGNALS ADDED)
PIC®
MCU
CONTROL
MRF24J40
ANTENNA
SPI
ZENA™ ANALYZER – MICROCHIP’S
ZigBee™ PROTOCOL STACK
CONFIGURATION TOOL AND
WIRELESS NETWORK ANALYZER
To assist in the development of ZigBee protocol
applications, Microchip provides a low-cost network
analyzer software, called ZENA. The ZENA PC
software also contains a tool to create applicationspecific configuration files and linker scripts for ZigBee
protocol applications. The ZENA demo software is
provided free as part of the Microchip Stack for the
ZigBee Protocol installation and is located in the
ZigBee2006Res directory. Refer to the “ZENA™
Wireless Network Analyzer User’s Guide” (DS51506)
for more information on using this tool.
The ZENA software provides the capability of creating
application-specific source files to support the
Microchip Stack and analyzing previously captured
wireless network traffic. The ZENA software, which
also includes the ability to capture real-time wireless
network activity, is also available as a separate kit and
includes an RF sniffer that can be connected to a PC
through a USB port.
Note:
INSTALLING SOURCE FILES
The complete Microchip Stack source code is available
for download from the Microchip web site. The source
code is distributed in a single Windows® operating
system installation file. Perform the following steps to
complete the installation:
1.
2.
3.
4.
Execute the installation file. A Windows operating
system installation wizard will guide you through
the installation process.
Before the software is installed, you must accept
the software license agreement by clicking
“I Accept”.
After completion of the installation process, you
should see the “Microchip Software Stack for
ZigBee” protocol program group. The complete
source code will be copied in the
ZigBee2006Res
subdirectory
in
the
Microchip
Solutions directory of your
computer.
Refer to the Readme file distributed with the
source code for the list of enhancements and
limitations of the installed version.
When ZENA software is used to configure a
ZigBee protocol application, it will create
three files for the application: zigbee.def,
myZigBee.c and zLink.lkr. The
zigbee.def and myZigBee.c files
contain information critical to the
configuration of the Stack. The zLink.lkr
is the linker script for the application. It is
highly recommended that you use ZENA
software to generate these files, rather than
editing the files manually, since the files are
interdependent. A linker script is not
required for the PIC24 C30 compiler
versions of the ZigBee protocol stack.
DS01232A-page 12
© 2008 Microchip Technology Inc.
AN1232
SOURCE FILE ORGANIZATION
The Microchip Stack consists of multiple source files.
For compatibility with other Microchip applications, files
that are common to multiple application notes are
TABLE 4:
stored in a single directory. ZigBee protocol Stackspecific files are stored in another directory. Each demo
application is stored in its own directory. Table 4 shows
the directory structure:
SOURCE FILE DIRECTORY STRUCTURE
Directory Name
Contents
DemoPIC18Coordinator
DemoPIC24Coordinator
Source code for a demonstration ZigBee protocol coordinator application. These files
can be changed to create a custom application.
DemoPIC18RFD
DemoPIC24FRFD
Source code for a demonstration ZigBee protocol RFD application. These files can be
changed to create a custom application.
DemoPIC18Router
DemoPIC24FRouter
Source code for a demonstration ZigBee protocol router application. These files can be
changed to create a custom application.
Documentation
Microchip Stack for the ZigBee Protocol documentation.
Microchip
Microchip Stack for the ZigBee Protocol source files. Files contained in this directory
should not be changed.
The Stack files contain logic for all supported device
types of ZigBee protocol applications; however, only
one set of logic will be enabled based on the
preprocessor definitions in the zigbee.def file
created by the ZENA software. A designer may
develop multiple ZigBee protocol node applications
using the common set of Stack source files, but
individual zigbee.def files. For example, each of the
demonstration applications has its own zigbee.def
file (and myZigBee.c file) in its respective directory.
This approach allows the development of multiple
applications using common source files, and generates
unique hex files depending on application-specific
options. This approach requires that when compiling an
application project, you provide search paths to include
files from the application, Microchip\Common, and
Microchip\ZigBeeStack source directories. The
demo application projects supplied with this application
note include the necessary search path information.
© 2008 Microchip Technology Inc.
Note:
When working with multiple projects, take
care when switching between projects. If the
projects’ Intermediates directories have
not been altered, the object files for the
Microchip Stack for the ZigBee Protocol will
be stored in the ZigBeeStack directory.
These files may not be considered “out of
date” when performing a project “Make”, and
erroneous capabilities may be linked in.
Symptoms of this problem include unusual,
unhandled primitives being returned to the
application layer. To ensure that the Stack
files have been compiled correctly for the
current project, store the object files in a
project unique directory by selecting Project>Build Options>Project from the main
menu. Change the Intermediates directory to a unique directory for the project. The
demo application projects supplied with this
application note already specify unique
Intermediates directories.
DS01232A-page 13
AN1232
DEMO APPLICATIONS
Versions 2.0-2.6 of the Microchip Stack include three
primary demonstration applications:
• DemoPIC18Coordinator/
DemoPIC24Coordinator – Demonstrates a
typical ZigBee protocol coordinator device
application.
• DemoPIC18RFD/DemoPIC24FRFD – Demonstrates a typical ZigBee protocol RFD device
application.
• DemoPIC18Router/DemoPIC24FRouter –
Demonstrates a typical ZigBee protocol router
device application.
Demo Application Features
One PICDEM Z or Explorer 16 Demonstration Board
must be programmed as a ZigBee protocol coordinator
using the DemoCoordinator project. A second board
must be programmed as a router using the
corresponding DemoPICXXRouter project. If more
PICDEM Z or Explorer 16 Demonstration Boards are
available, they can be programmed either as more end
devices or as routers using the appropriate project.
Demo Applications Project and
Source Files
Table 5 through Table 9 list the source files required to
implement the Microchip Stack for the ZigBee Protocol
and the demo applications. Note that additional files may
be provided in the ZigBeeStack directory as additional
transceivers are supported.
The demo applications implement the following features:
• Targeted for use with the PICDEM Z and Explorer
16 demo boards.
• Demonstrates a polling end device operation.
• RS-232 terminal output to view device operation,
as well as a menu system to send commands to
the operating devices.
• Operates a simple multicast addressing
application.
MICROCHIP STACK SOURCE FILES IN ZigBeeStack SUBDIRECTORY
TABLE 5:
File Name
Description
SymbolTime.c, .h
Performs timing functions for the Microchip Stack for the ZigBee™ protocol.
zAPL.h
Application level interface header file for the Stack. This is the only file that the
application code needs to include.
zAPS.c, .h
ZigBee protocol APS layer.
zTest.h
ZigBee ZCP profile information. This changes depending on the profile.
zigbee.h
Generic ZigBee protocol constants.
ZigBeeTasks.c, .h
Directs program flow through the Stack layers.
zMAC.h
Generic IEEE 802.15.4™ MAC layer header file.
zMAC_MRF24J40.c, .h
IEEE 802.15.4 MAC layer for the Microchip MRF24J40 transceiver.
zNVM.c, .h
Performs nonvolatile memory storage functions.
zNWK.c, .h
ZigBee protocol NWK layer.
zPHY.h
Generic IEEE 802.15.4 PHY layer header file.
zPHY_MRF24J40.c, .h
IEEE 802.15.4 PHY layer for the Microchip MRF24J40 transceiver.
zSecurity.h
ZigBee protocol security layer header file.
zSecurity_MRF24J40.c, .h
ZigBee protocol security layer for the Microchip MRF24J40 transceiver.
zZDO.c, .h
ZigBee protocol’s ZDO (ZDP) layer.
DS01232A-page 14
© 2008 Microchip Technology Inc.
AN1232
TABLE 6:
MICROCHIP COMMON SOURCE FILES IN
Common SUBDIRECTORY
File Name
Description
Compiler.h
Compiler-specific definitions.
Console.c, .h
USART interface code (optional).
Generic.h
Generic constants and type definitions.
MSPI.c, .h
SPI interface code
sralloc.c, .h
Dynamic memory allocation (heap) code.
ZigBee™ PROTOCOL COORDINATOR DEMO IN DemoPIC18Coordinator
AND DemoPIC24Coordinator SUBDIRECTORIES
TABLE 7:
File Name
Description
Coordinator.c
Main application source file.
DemoPIC18Coordinator.mcp
DemoPIC24Coordinator.mcp
Project file.
DemoPIC18Coordinator.mcw
DemoPIC24Coordinator.mcw
Work space file.
myZigBee.c
Generated by ZENA™ software. Contains application-specific information.
zigbee.def
Generated by ZENA software. Contains application-specific information.
zLink.lkr
Generated by ZENA software. Project linker script.
ZigBee™ PROTOCOL ROUTER DEMO IN DemoPIC18Router AND
DemoPIC24FRouter SUBDIRECTORIES
TABLE 8:
File Name
Description
Router.c
Main application source file.
DemoPIC18Router.mcp
DemoPIC24FRouter.mcp
Project file.
DemoPIC18Router.mcw
DemoPIC24FRouter.mcw
Work space file.
myZigBee.c
Generated by ZENA™ software. Contains application-specific information.
zigbee.def
Generated by ZENA software. Contains application-specific information.
zLink.lkr
Generated by ZENA software. Project linker script.
TABLE 9:
ZigBee™ PROTOCOL END DEVICE DEMO IN
DemoPIC24RFD SUBDIRECTORIES
File Name
DemoPIC18RFD AND
Description
RFD.c
Main application source file.
DemoPIC18RFD.mcp
DemoPIC24FRFD.mcp
Project file.
DemoPIC18RFD.mcw
DemoPIC24FRFD.mcw
Work space file.
myZigBee.c
Generated by ZENA™ software. Contains application-specific information.
zigbee.def
Generated by ZENA software. Contains application-specific information.
zLink.lkr
Generated by ZENA software. Project linker script.
© 2008 Microchip Technology Inc.
DS01232A-page 15
AN1232
Building Primary Demo Applications
The following is a high-level procedure for building demo
applications. This procedure assumes that you are
familiar with MPLAB® IDE and will be using MPLAB IDE
to build the applications. If not, refer to your MPLAB IDE
application-specific instructions to create, open and
build a project.
1.
2.
3.
4.
Make sure that the source files for the Microchip
Stack for the ZigBee Protocol are installed. If
not, please refer to “Installing Source Files”.
Double click on the appropriate project file:
DemoPIC18Coordinator\DemoPIC24Coor
dinator.mcp for the demo ZigBee protocol
coordinator
application,
DemoPIC18RFD\
DemoPIC24FRFD.mcp for the demo RFD
application
or
DemoPIC18Router\DemoPIC24FRouter.mcp
for the demo ZigBee protocol router application.
Use MPLAB IDE menu commands to build the
project. Note that the demo application projects
are created to work correctly when the source
files are located in the ZigBee2006Res
directory. If you have moved the source files to
another location, you may need to modify existing project settings to build.
The build process should finish successfully. If
not, make sure your MPLAB IDE and compiler
are set up properly, and your project options are
correct.
Programming Primary Demo
Applications
To program a target with either of the two demo
applications, you must have access to a Microchip programmer. The following procedure assumes that you
will be using MPLAB ICD 2 as a programmer. If not,
please refer to your specific programmer instructions.
1.
2.
3.
4.
5.
Connect MPLAB ICD 2 to the PICDEM Z demo
board or your target board.
Apply power to the target board.
Launch MPLAB IDE.
Select the Microchip device of your choice
(required only if you are importing a hex file
previously built).
Enable MPLAB ICD 2 as a programmer and
select the Connect option from the MPLAB ICD 2
programmer menu to connect to MPLAB ICD 2
and perform a self-test.
6.
If you have just rebuilt the project as described
above, proceed to the next step. If you want to
use a previously built hex file, import the
DemoPIC18Coordinator\DemoPIC24Coord
inator.hex
file,
the
DemoPIC18RFD\DemoPIC24FRFD.hex file or
the
DemoPIC18Router\DemoPIC24FRouter.he
x file. Be sure that you use some identification
method to identify the different nodes into which
you will download the different types of
applications.
7. All demo application files contain the necessary
configuration options required for the PICDEM Z
or Explorer 16 demo boards. If you are programming another type of board, make sure that you
select the appropriate oscillator mode from the
MPLAB IDE configuration settings menu.
8. Select the Program menu option from the
MPLAB ICD 2 programmer menu to begin
programming the target.
9. After a few seconds, you should see the message, “Programming successful”. If not,
double check your board and MPLAB ICD 2
connection. Refer to MPLAB IDE on-line help for
further assistance.
10. Disconnect the MPLAB ICD 2 cable from the
target board.
Running the Primary Demo Applications
To run the demo, program one of the demo platform
boards as a ZigBee protocol coordinator, and the other
as a Router, using the demo applications provided. To
view node operation, it is recommended that you connect the RS-232 connector on each demo board to a
serial port on a PC, and use HyperTerminal or another
serial interface software to communicate with the demo
board. Configure the port with the following settings:
19200 bps, 8 data bytes, 1 Stop bit, no parity and no
flow control.
Apply power to the coordinator node. You should see
the following message on the HyperTerminal window:
*************************************
Microchip ZigBee(TM) Stack - v2.0-2.6
ZigBee Coordinator
The coordinator will then automatically try to find an
available wireless channel and form a new network. If
successful, it will display the following message:
Trying to start network...
PAN #### started successfully.
Where #### is a four-digit hexadecimal number,
indicating the PAN ID of the network it has successfully
formed. It will then enable joining of the network by
other nodes and display the following message:
Joining permitted.
At this point, other nodes may join the network.
DS01232A-page 16
© 2008 Microchip Technology Inc.
AN1232
Apply power to the router node. You should see the
following message on the corresponding HyperTerminal
window:
USING THE MICROCHIP STACK FOR
THE ZigBee PROTOCOL
*************************************
Microchip ZigBee(TM) Stack - v2.0-2.6
ZigBee Router
To design a ZigBee protocol system, you must do the
following:
1.
The router will then try to find a network to join. If it is
successful, it will display the following message:
2.
Trying to join network as a new device...
Network(s) found. Trying to join ####.
Join successful!
3.
4.
The coordinator will recognize that the new node has
joined by displaying the following message:
Node #### with MAC Address
**************** just joined.
5.
6.
Obtain an OUI (see “IEEE Extended Unique
Identifiers – EUI-64”).
Determine the radio needed based on data rate
and geographical market needs.
Select a suitable Microchip MCU.
Develop the ZigBee protocol application using
the Stack provided application note.
Perform all RF compliance certifications.
Perform ZigBee protocol interoperability
compliance certification.
Where #### is the assigned short address of the new
node.
Follow these basic steps to develop a ZigBee protocol
application:
At this point, the router has successfully joined the network and is polling for messages. If the device is programmed with the RFD hex file, two LEDs, RA0/D10
and RA1/D9, will blink on and off at the polling rate of
the RFD. The default setting is to blink once every two
seconds. Further operation depends on the
configuration of the nodes.
1.
2.
3.
4.
Demonstrating Sample Applications
Please consult the ZigBeeQuickStartGuide.pdf
document in the stack install directory for a complete
guide on how to run the sample applications that came
with this version of the Stack.
5.
6.
© 2008 Microchip Technology Inc.
Determine the profile that the system will use.
Determine the endpoint structure that each
device will use.
Create a new project directory. Place all
application-specific source files and project
files in this directory.
Use ZENA software to generate configuration files
based on the device type, device configuration
and endpoint structure. Compare the ZENA software generated files against those that came with
the Stack, and make appropriate changes as
needed based on your specific hardware
requirements.
Use the sample application that came with the
Stack as a guide in creating a new application.
Add code in the new application, including extra
initialization, any required ZDO response
handling, endpoint message reception and
transmission, and any non-protocol processing
and interrupt handling.
DS01232A-page 17
AN1232
Interfacing with the Microchip Stack for
the ZigBee Protocol
The application source code must include the header
file, zAPL.h , to access the ZigBee protocol functions.
#include “zAPL.h”
A ZigBee protocol coordinator application will need to
have one support variable to keep track of the current
primitive being executed by the Stack.
The application now interfaces with the Stack through
the primitives defined in the ZigBee protocol and
IEEE 802.15.4 specifications. Stack operation is triggered by calling the function, ZigBeeTasks(). Stack
operation will continue until the requested primitive
path is complete or an application-level primitive needs
to be processed.
Note:
ZIGBEE_PRIMITIVE currentPrimitive;
A ZigBee protocol router or end device will also need to
keep track of the current primitive; but, in addition, it will
need two other support variables to assist in network
discovery and joining.
NETWORK_DESCRIPTOR * currentNetworkDescriptor;
ZIGBEE_PRIMITIVE currentPrimitive;
NETWORK_DESCRIPTOR * NetworkDescriptor;
Next, the application must configure all pins required to
interface with the transceiver. The ZENA analyzer will
create several labels that may be used to access the
required LAT and TRIS bits. Refer to the Readme file
for the labels created for the supported transceivers.
Before the Stack can be used, it must be initialized.
Interrupts must then be enabled. For example, on the
PIC18 platform, the following lines of code would
accomplish this:
Refer to the ZigBee protocol and
IEEE 802.15.4 specifications for the
complete list of primitives and their
parameters.
Since only one primitive can be processed at one time,
a single data structure (a union) is used to hold all the
primitive parameters. This structure can be viewed in
the file, ZigBeeTasks.h. Take care when accessing
this structure to avoid overwriting a parameter before
using it. After processing a primitive, it is critical that the
current primitive be set to the next primitive to execute
(or NO_PRIMITIVE) to avoid an infinite loop (see
Example 1). Refer to the “Primitive Summary” section for a list of the common primitives used by the
application layer.
Default processing for most primitives is included in the
sample application files. Two primitives will require
additional
application-specific
code:
APSDE_DATA_indication and NO_PRIMITIVE.
ZigBeeInit(); INTCONbits.RBIE = 1
RCONbits.IPEN = 1;
INTCONbits.GIEH = 1;
EXAMPLE 1:
THE BASIC STRUCTURE OF THE APPLICATION
while (1)
{
/* Clear the watch dog timer */
CLRWDT();
/* Process the current ZigBee Primitive */
ZigBeeTasks( &currentPrimitive );
/* Determine the next ZigBee Primitive to process */
ProcessZigBeePrimitives();
/* do any non ZigBee related tasks here */
ProcessNONZigBeeTasks();
}
DS01232A-page 18
© 2008 Microchip Technology Inc.
AN1232
Forming or Joining a Network
Receiving Messages
The process of forming or joining a network is shown in
the sample applications. The process is initiated in the
NO_PRIMITIVE primitive handling. If the device is a
ZigBee protocol coordinator, and if it has not formed
a network, then it will begin the process of trying
to
form
a
network
by
issuing
the
NLME_NETWORK_FORMATION_request primitive.
The Stack notifies the application of received
messages through the APSDE_DATA_indication
primitive. When this primitive is returned, the
APSDE_DATA_indication primitive parameters are
populated with information about the message and the
received message resides in a buffer. Use the function,
APLGet(), to extract each byte of the message from
the buffer.
If the device is not a ZigBee protocol coordinator and it
is not currently on a network, it will try to join one. If the
device has determined that it was previously on a
network, then it will try to join as an orphan by issuing
the NLME_JOIN_request with the RejoinNetwork
parameter set to TRUE. If that fails, or if the device was
not previously on a network, then it will try to join
as a new node. It will first issue the
NLME_NETWORK_DISCOVERY_request primitive to
discover what networks are available. The application
code will then select one of the discovered networks
and try to join it by issuing the NLME_JOIN_request
with the RejoinNetwork parameter set to FALSE.
See “ZigBee Protocol Timing” for timing requirements
used during this process.
EXAMPLE 2:
The DstEndpoint parameter indicates the destination endpoint for the message. If it is a valid endpoint,
the message can be processed (see Example 2).
Note 1: A case for the ZDO endpoint (endpoint 0)
must be included to handle responses to
all ZDO messages sent by the application.
2: After the message is processed, it must
be discarded using the APLDiscard()
function. Failure to discard the message
will result in no further messages being
processed.
RECEIVING MESSAGES
case APSDE_DATA_indication:
{
// Declare variables used by this primitive.
currentPrimitive = NO_PRIMITIVE;
frameHeader = APLGet();
// This may change during processing.
switch (params.APSDE_DATA_indication.DstEndpoint)
{
case EP_ZDO:
// Handle all ZDO responses to requests we sent.
break;
// Include cases for all application endpoints.
}
APLDiscard();
}
break;
© 2008 Microchip Technology Inc.
DS01232A-page 19
AN1232
Sending Messages
The Microchip Stack for the ZigBee Protocol allows one
outgoing message in the application layer at a time.
Messages are sent by implementing the following:
1.
2.
3.
4.
5.
Verify that the application layer is ready for a new
outgoing
message
by
confirming
that
ZigBeeReady() is TRUE.
Lock the system with ZigBeeBlockTx() so
subsequent calls to ZigBeeReady() will return
FALSE.
Load the message payload into the array TxBuffer, using TxData to index through the array.
When complete, TxData must point to the first
location after the message (i.e., TxData equals
the length of the data).
Load the APSDE_DATA_request primitive
parameters.
Set
currentPrimitive
to
APSDE_DATA_request and call ZigBeeTasks().
Messages are typically sent by the application in two
places:
The process of sending a message is identical for both
locations. Example 3 shows how to send a unicast
message to a specific device of interest. The following
should be noted:
• Each APS frame must be directed a particular end
point and Cluster within that Profile.
• TxData must point to the next available location,
so TxBuffer is loaded using post-increment
addressing.
• Direct message to a specific endpoint (Applet) on
the target device.
• Force the use of tree routing. Otherwise, the
application might trigger a route request prior to
sending out the message.
• We are requesting that the message be routed, if
possible.
The status of the transmitted message will be returned
via the APSDE_DATA_confirm primitive. Note that if the
message fails to transmit, the Stack will automatically
handle retrying the message, apscMaxFrameRetries
times.
• In APSDE_DATA_indication processing, in
response to a received message.
• In NO_PRIMITIVE processing, in response to an
application event.
DS01232A-page 20
© 2008 Microchip Technology Inc.
AN1232
EXAMPLE 3:
SENDING AN OUTGOING MESSAGE
if (ZigBeeReady())
{
/* Send a message to device whose network address is destinationAddress
if( myStatusFlags.bits.bmyBottonWasPressed )
{
myStatusFlags.bits. bmyBottonWasPressed = FALSE;
*/
/* Block the transmit path before loading the message payload */
ZigBeeBlockTx();
/* requesting 10-bytes of data from the receiving device */
TxBuffer[TxData++] = 0x0a;
/* Use unicast, 16-bit network address */
params.APSDE_DATA_request.DstAddrMode = APS_ADDRESS_16_BIT;
/* Destination address of devices of interest, including endpoint */
params.APSDE_DATA_request.DstAddress.ShortAddr = destinationAddress;
params.APSDE_DATA_request.DstEndPoint
= destinationEndPoint;
/* Using the ZCP profileID and ClusterIDs as an example */
params.APSDE_DATA_request.ProfileId.Val = MY_PROFILE_ID;
params.APSDE_DATA_request.ClusterId.Val = BUFFER_TEST_REQUEST_CLUSTER;
params.APSDE_DATA_request.SrcEndpoint
= EP_BUTTON_APPLET;
params.APSDE_DATA_request.RadiusCounter = DEFAULT_RADIUS;
/* Find a route if possible */
params.APSDE_DATA_request.DiscoverRoute = ROUTE_DISCOVERY_ENABLE;
params.APSDE_DATA_request.TxOptions.Val = 0;
/* request an ACK from application on receiving device */
params.APSDE_DATA_request.TxOptions.bits.acknowledged = 1;
/* Trigger the next primitive to be executed */
currentPrimitive = APSDE_DATA_request;
}
}
© 2008 Microchip Technology Inc.
DS01232A-page 21
AN1232
Requesting and Receiving Data
on an RFD
Since RFDs normally power off their transceiver when
they are Idle to conserve power, they must request
messages when their transceiver is on by issuing the
NLME_SYNC_request primitive. Example 4 demonstrates a typical sequence for going to Sleep, and
waking back up using the Watchdog Timer, or a button
press to wake-up. We can Sleep if all of the following are
true:
• There is no ZigBee protocol primitive ready to be
processed.
• The Stack is not performing background tasks.
• The previous data request is complete.
• All application-specific processes are complete.
EXAMPLE 4:
After waking from Sleep, the RFD must request data
from its parent using the NLME_SYNC_request primitive. The RFD will receive one of the following
responses from issuing an NLME_SYNC_request:
• If the RFD’s parent has messages buffered for the
device, it will send one, and the RFD will generate
an APSDE_DATA_indication primitive.
• If the parent device does not have any buffered
messages for the RFD, the RFD will generate an
NLME_SYNC_confirm primitive with a status of
SUCCESS.
If the RFD receives no response from its parent, the
RFD will generate an NLME_SYNC_confirm primitive
with a status of NWK_SYNC_FAILURE.
REQUESTING AND RECEIVING DATA ON AN RFD
// If we don't have to execute a primitive, see if we need to request
// data from our parent, or if we can go to sleep.
if (currentPrimitive == NO_PRIMITIVE)
{
if (!ZigBeeStatus.flags.bits.bDataRequestComplete)
{
// We have not received all data from our parent. If we are not waiting
// for an answer from a data request, send a data request.
if (!ZigBeeStatus.flags.bits.bRequestingData)
{
if (ZigBeeReady())
{
// Our parent still may have data for us.
params.NLME_SYNC_request.Track = FALSE;
currentPrimitive = NLME_SYNC_request;
}
}
}
else
{
if (!ZigBeeStatus.flags.bits.bHasBackgroundTasks &&
!ZigBeeStatus.flags.bits.bRadioIsSleeping)
{
// We do not have a primitive to execute, we've extracted all messages
// that our parent has for us, the stack has no background tasks,
// and all application-specific processes are complete.
// Now we can go to sleep. Make sure that the UART is finished,
// turn off the transceiver, and make sure that we wakeup from key press.
while (!ConsoleIsPutReady());
MRF24J40Sleep();
INTCONbits.RBIE = 1;
SLEEP();
NOP();
// We just woke up from sleep. Turn on the transceiver and
// request data from our parent.
MRF24J40Wake();
params.NLME_SYNC_request.Track = FALSE;
currentPrimitive = NLME_SYNC_request;
}
}
}
DS01232A-page 22
© 2008 Microchip Technology Inc.
AN1232
Secure Transmission
The Microchip Stack for the ZigBee Protocol supports
all seven security modes that are defined in the ZigBee
protocol specification to protect the output packets.
The security modes can be categorized into three
groups:
• Message Integrity Code (MIC) – Security modes
ensure the integrity of the packet. The MIC
attached to the packet (the size of which is determined by the particular mode) ensures that the
packet, including the header and payload, has not
been modified in any way during transmission.
The packet payload is not encrypted in these
modes.
• Encryption (ENC) – Security mode encrypts the
payload. The plaintext content of the payload cannot be exposed without a valid security key. This
mode cannot verify frame integrity or the content
of the header, including the source of the original
packet and the frame counter.
• ENC-MIC – Security modes are a combination of
the two previous groups. In these modes, the payload is encrypted. At the same time, the header
and payload’s integrity is protected by the MIC
attached at the end of the packet.
In addition, there is also Security mode, 0x00, which
specifies no security. Essentially, this is the Stack operating with the security module turned off. The capability
of each of the security modes can be found in Table 10.
TABLE 10:
The ZigBee protocol specification also defines support
for Residential and Commercial Security modes, based
on the use of security keys. The main difference
between the two is that Commercial mode requires the
generation of an individual security key between two
nodes while communicating, while Residential mode
uses the unique network key within the network to
secure packets. Currently, the Microchip Stack for the
ZigBee Protocol supports only Residential mode.
The Stack supports networks with or without a preconfigured security key. Security is supported in either
the NWK or the APL layer, depending on the requirements of the application profile. MAC layer security
support can also be enabled.
The Stack adds an auxiliary security header before the
security payload of every secured packet. The format
of the auxiliary security header format can be found in
Table 11.
The ZigBee security protocol specifies the nonce to be
the combination of three items:
• the frame counter
• the source long address
• the key sequence number (for MAC layer) or the
security control byte (for NWK and APL layers)
As the result, if MAC layer security is turned on, the
source address mode in the MAC layer must be
Extended Address mode (0x03). If APL layer security is
turned on, the device that decrypts the packet must be
able to match the packet source short address to its
source long address. This is done using the APS
address map table.
ZigBee™ PROTOCOL SECURITY SERVICES
Security Mode
Identifier
Name
0x01
MIC-32
Security Service
Access Control Data Encryption
Frame Integrity
MIC Length
(Bytes)
X
4
X
0x02
MIC-64
X
X
8
0x03
MIC-128
X
X
16
0x04
ENC
X
X
0x05
ENC-MIC-32
X
X
X
0x06
ENC-MIC-64
X
X
X
8
0x07
ENC-MIC-128
X
X
X
16
TABLE 11:
0
4
ZigBee™ PROTOCOL AUXILIARY SECURITY HEADER FORMAT
Packet Header Feature
Security Location
Security Control
(1 Byte)
MAC Layer Security
Frame Counter
(4 Bytes)
X
NWK Layer Security
X
X
APL Layer Security
X
X
© 2008 Microchip Technology Inc.
Source Extended
Address
(8 Bytes)
Key Sequence
Number
(1 Byte)
X
X
X
X
DS01232A-page 23
AN1232
The Stack is capable of ensuring sequential freshness
by checking the transmitted frame counter. Only the
frame counter of packets from family members (parent
or children) will be checked, since only family member
knows when a device joins the network. Packets that
are from family members but do not meet the
sequential freshness requirement will be discarded.
The maximum length of a transmitted message is
127 bytes. When the security module is turned on,
between 5 and 29 additional bytes are required for the
auxiliary security header and the MIC, depending on
the combination of security mode and secured layer.
Users will need to balance the security needs and the
impact on the data payload size (and associated performance impact) associated with the combination of
security settings.
EXAMPLE 5:
The security mode and secured layer settings are
defined in the application profile. Use the ZENA Wireless Network Analyzer configuration tool to set up all
other critical security options.
Once the security mode has been defined, sending the
secured packet is straightforward; only one modification is required in the application code. Example 5
shows the exact same code as in Example 3, with the
additional code to enable secure transmission shown in
bold.
SENDING A SECURED OUTGOING MESSAGE
if (ZigBeeReady() )
{
if (bLightSwitchToggled)
{
bLightSwitchToggled = FALSE;
ZigBeeBlockTx();
TxBuffer[TxData++] = 0x08
/*request eight bytes*/
params.APSDE_DATA_request.DstAddrMode = APS_ADDRESS_16_BIT;
params.APSDE_DATA_request.DstEndpoint = destinationEndpoint;
params.APSDE_DATA_request.DstAddress.ShortAddr = destinationAddress;
params.APSDE_DATA_request.ProfileId.Val = MY_PROFILE_ID;
params.APSDE_DATA_request.RadiusCounter = DEFAULT_RADIUS;
params.APSDE_DATA_request.DiscoverRoute = ROUTE_DISCOVERY_ENABLE;
params.APSDE_DATA_request.TxOptions.Val = 0;
params.APSDE_DATA_request.TxOptions.bits.securityEnabled = 1;
params.APSDE_DATA_request.SrcEndpoint = EP_SWITCH;
params.APSDE_DATA_request.ClusterId.Val = BUFFER_TEST_REQUEST_CLUSTER;
currentPrimitive = APSDE_DATA_request;
}
}
DS01232A-page 24
© 2008 Microchip Technology Inc.
AN1232
Primitive Summary
The application layer communicates with the Stack
primarily through the primitives defined in the ZigBee
protocol and IEEE 802.15.4 specifications. Table 12
describes the primitives that are commonly issued by
the application layer and their response primitive. Not
all devices will issue all of these primitives.
TABLE 12:
Some primitives that are received by the application
layer are generated by the Stack itself, not as a
response to an application primitive. The application
layer must be able to handle these primitives as well.
Table 13 shows all the primitives that can be returned
to the application layer. Default processing for most of
the primitives is included in the application templates.
TYPICAL APPLICATION PRIMITIVES AND RESPONSES
Application Issued Primitive
Response Primitive
Description
APSDE_DATA_request
APSDE_DATA_confirm
Used to send messages to other devices.
APSME_BIND_request
APSME_BIND_confirm
Force the creating of a binding. Can be used only
on devices that support binding.
APSME_UNBIND_request
APSME_UNBIND_confirm
Force the removal of a binding. Can be used only
on devices that support binding.
NLME_NETWORK_DISCOVERY_ NLME_NETWORK_DISCOVERY_ Discover networks available for joining. Not used
request
confirm
by ZigBee™ protocol coordinators.
NLME_NETWORK_FORMATION_ NLME_NETWORK_FORMATION_ Start a network on one of the specified channels.
request
confirm
ZigBee protocol coordinators only.
NLME_PERMIT_JOINING_
request
NLME_PERMIT_JOINING_
confirm
Allow other nodes to join the network as our
children. ZigBee protocol coordinators and routers
only.
NLME_START_ROUTER_
request
NLME_START_ROUTER_
confirm
Start routing functionality. Routers only.
NLME_JOIN_request
NLME_JOIN_confirm
Try to rejoin or join the specified network. Not used
by ZigBee protocol coordinators.
NLME_DIRECT_JOIN_
request
NLME_DIRECT_JOIN_
confirm
Add a device as a child device. ZigBee protocol
coordinators and routers only.
NLME_LEAVE_request
NLME_LEAVE_confirm
Leave the network or force a child device to leave
the network.
NLME_SYNC_request
NLME_SYNC_confirm
Request buffered messages from the device’s
parent. RFDs only.
APSME_ADD_GROUP_request APSME_ADD_GROUP_confirm Request membership in particular group to an endpoint. Can be used only on devices that support
multicast addressing.
APSME_REMOVE_GROUP_requ APSME_REMOVE_GROUP_conf Remove membership in particular group from an
est
irm
endpoint. Can be used only on devices that support multicast addressing.
APSME_REMOVE_ALL_GROUPS APSME_REMOVE_ALL_GROUPS Remove membership in all groups from an end_request
_confirm
point. Can be used only on devices that support
multicast addressing.
NETWORK_ROUTE_DISCOVERY NETWORK_ROUTE_DISCOVERY Initiate route discovery to another device. ZigBee
_request
_confirm
protocol Coordinator and Routers only.
© 2008 Microchip Technology Inc.
DS01232A-page 25
AN1232
TABLE 13:
PRIMITIVE HANDLING REQUIREMENTS
Primitive
APSDE_DATA_confirm
ZigBee™ Protocol
Coordinator
ZigBee Protocol
Router
FFD End
Device
RFD End
Device
X
X
X
X
X
X
(Note 2)
(Note 2)
(Note 2)
X
X
X
X(1)
X
X
APSME_BIND_confirm
X(5)
X(3,5)
APSME_UNBIND_confirm
X(5)
X(3,5)
APSDE_DATA_indication
NLME_DIRECT_JOIN_confirm
NLME_GET_confirm
(5)
X(4)
X
(Note 2)
NLME_JOIN_confirm
NLME_JOIN_indication
NLME_LEAVE_confirm
NLME_LEAVE_indication
X
X
X(1)
X(1)
X(1)
X
X
X
X
X
X
X
NLME_NETWORK_DISCOVERY_confirm
NLME_NETWORK_FORMATION_confirm
X
NLME_PERMIT_JOINING_confirm
X
X
X
X
X
(Note 2)
(Note 2)
(Note 2)
(Note 2)
X
X
X
X
X
NLME_RESET_confirm
NLME_SET_confirm
NLME_START_ROUTER_confirm
NO_PRIMITIVE
Note 1:
2:
3:
4:
5:
X
Required if application will issue an NLME_LEAVE_request to another node.
These primitives are not used. Stack attribute manipulation is done directly.
Required if binding is supported.
Required if application will issue an NLME_DIRECT_JOIN_request.
Required if application issues the corresponding BIND/UNBIND_request.
SYSTEM RESOURCE CLEAN-UP
It is required that all unnecessary system resources are
cleaned up after invoking a primitive. The Microchip
ZigBee protocol Stack already handles most of the clean
up in the Stack. Currently, there is only one primitive,
NLME_JOIN_confirm, which is handled by the application layer and needs to be cleaned up by the user.
ZigBee protocol devices other than the Coordinator usually invoke NLME_NETWORK_DISCOVERY_request to
find the current available networks before deciding
which
network
to
join.
The
primitive,
EXAMPLE 6:
NLME_NETWORK_DISCOVERY_confirm, returns a link
list of the available networks for the user to choose from.
Upon joining the network, the link list of available networks must be removed to free the system resources
when receiving primitive NLME_JOIN_confirm.
Example 6 shows how to free the available network list
in the primitive NLME_JOIN_confirm.
Keep in mind that this procedure has been
implemented in the Microchip ZigBee protocol demo
projects as well as in the application template.
CLEANING UP SYSTEM RESOURCES
while (NetworkDescriptor)
{
currentNetworkDescriptor = NetworkDescriptor->next;
free( NetworkDescriptor );
NetworkDescriptor = currentNetworkDescriptor;
}
DS01232A-page 26
© 2008 Microchip Technology Inc.
AN1232
Microchip Stack for the ZigBee Protocol Macros and Functions
APLDisable
Description
This function disables the transceiver.
Syntax
BOOL APLDisable( void );
Inputs
None
Outputs
TRUE – If the transceiver was put into Reset.
FALSE – If the current Stack activity prohibits putting the transceiver into Reset.
Notes
Typically, this function is used only by RFDs to conserve power while in Sleep.
APLDiscard
Description
This function discards the current received message. It should be called when processing of the current message is
complete.
Syntax
void APLDiscard( void );
Inputs
None
Outputs
None
Notes
Failure to call this function will result in the Stack being unable to process, and ultimately, receive messages. Refer to
the template files for typical usage of this function.
APLEnable
Description
This function enables the transceiver.
Syntax
void APLEnable(void );
Inputs
None
Outputs
None
© 2008 Microchip Technology Inc.
DS01232A-page 27
AN1232
Notes
Typically, it is used only by RFDs when they wake-up from Sleep. It is not necessary to call this function in any other
location.
APLGet
Description
This function retrieves a byte from the current received message.
Syntax
BYTE APLGet( void );
Inputs
None
Outputs
The next byte of the current received message.
Notes
If this function is called after all message bytes have been retrieved, this function will return 0x00.
APLGetTransId
Description
This function retrieves the next APS Transaction Identification value to use in an outgoing message.
Syntax
BYTE APLGetTransId( void );
Inputs
None
Outputs
The next Transaction ID value.
Notes
None
AddGroup
Description
This function used to request membership in particular group to an endpoint.
Syntax
BYTE
AddGroup(WORD_VAL GroupAddress, BYTE EndPoint) Inputs
GroupAddress is the 16-bit value of the GroupID of the group to which membership is been requested
EndPoint is the endpoint associated with the GroupID value
Outputs
BYTE
GROUP_SUCCESS – if entry was successfully added to GroupTable
BYTE
GROUP_TABLE_FULL – if GroupTable was full
BYTE
GROUP_INVALID_PARAMETER
DS01232A-page 28
© 2008 Microchip Technology Inc.
AN1232
Notes
Only for devices that support multicasting.
ClearBindingTable
Description
This function removes all the entries from the binding table that were stored in nonvolatile memory.
Syntax
void ClearBindingTable (void );
Inputs
None
Outputs
None
Notes
Only for devices that support bindings.
RemoveAllBindings
Description
This function removes all the entries from the binding table from a particular source device.
Syntax
void RemoveAllBindings( SHORT_ADDR shortAddr );
Inputs
The network address of the source device from which to remove the bindings.
Outputs
None
Notes
Only for devices that support bindings.
RemoveAllGroups
Description
This function is used to remove membership in all groups from an endpoint.
Syntax
void RemoveAllGroups(void);
Inputs
None
Outputs
None
Notes
Can be used only on devices that support multicast addressing syntax.
© 2008 Microchip Technology Inc.
DS01232A-page 29
AN1232
NWKClearNeighborTable
Description
This function removes all the entries from the Neighbor Table that were stored in nonvolatile memory.
Syntax
void NWKClearNeighborTable (void );
Inputs
None
Outputs
None
Notes
Only for devices that support bindings.
ZigBeeBlockTx
Description
This function locks the transmit buffer.
Syntax
void ZigBeeBlockTx( void );
Inputs
None
Outputs
None
Notes
After calling ZigBeeReady() to confirm that the transmit buffer (TxBuffer) is ready for use, this function should be
called so that subsequent calls to ZigBeeReady() will return FALSE.
ZigBeeInit
Description
This function initializes the Stack. It must be called before any other Stack functions. All hardware pin configuration and
directioning must be performed before this function is called.
Syntax
void ZigBeeInit( void );
Inputs
None
Outputs
None
Notes
None
DS01232A-page 30
© 2008 Microchip Technology Inc.
AN1232
ZigBeeReady
Description
This function indicates whether or not the Stack is ready to initiate an outgoing message.
Syntax
BOOL ZigBeeReady( void );
Inputs
None
Outputs
TRUE – A new outgoing message may be loaded into TxBuffer.
FALSE – An earlier message is still being processed and TxBuffer is still in use.
Notes
None
ZigBeeTasks
Description
This function triggers Stack operation. The current primitive to execute must be passed in *primitive. If no primitive
is required to execute, set *primitive to NO_PRIMITIVE. The function will continue until a user primitive is generated
(including NO_PRIMITIVE). On exit, it will return TRUE if the Stack still has background tasks to execute. This function
must be called on a regular basis in order for the Stack to function properly, even if it returns FALSE. Message reception
from the transceiver is triggered by an interrupt which requests a background task.
Syntax
BOOL ZigBeeTasks( ZIGBEE_PRIMITIVE *primitive );
Inputs
*primitive – Pointer to the value of the next primitive to execute.
Outputs
TRUE – The Stack still has background tasks to execute.
FALSE – The Stack does not have background tasks to execute.
*primitive – Pointer to the value of the next primitive to execute.
Notes
None
© 2008 Microchip Technology Inc.
DS01232A-page 31
AN1232
Microchip Stack for the ZigBee Protocol
Status Flags
The Stack has several status flags that may be viewed
by the application. The application must not modify
these flags or Stack operation will be corrupted. All
flags are located in the ZigBeeStatus.flags.bits
structure.
TABLE 14:
STACK STATUS FLAGS
Flag
Description
bTxFIFOInUse
Indicates that the Stack is currently in the process of transmitting an outgoing
message. Use the macros, ZigBeeReady() to check, and ZigBeeBlockTx() to
set, this flag.
bRxBufferOverflow
Indicates that the receive buffer has overflowed and messages have been dropped.
Must be cleared by the application.
bHasBackgroundTasks
Updated by ZigBeeTasks(). Indicates if the Stack still has background tasks in
progress.
bNetworkFormed
ZigBee™ protocol coordinator only. Indicates that the device has successfully formed
a network.
bTryingToFormNetwork
ZigBee protocol coordinator only. Indicates that the device is in the process of trying
to form a network.
bNetworkJoined
ZigBee protocol routers and end devices. Indicates that the device has successfully
joined a network.
bTryingToJoinNetwork
ZigBee protocol routers and end devices. Indicates that the device is in the process of
trying to join a network.
bTryOrphanJoin
ZigBee protocol routers and end devices. Indicates that the device was once part of a
network and should try to join as an orphan.
bRequestingData
RFD end devices only. Indicates that the device is in the process of requesting data
from its parent.
bDataRequestComplete
RFD end devices only. Indicates that the current request for data is complete and the
device may be able to go to Sleep.
Configuration Parameters
MAX APS ACK FRAMES GENERATED
The Microchip Stack for the ZigBee Protocol is highly
configurable using the ZENA Wireless Network
Analyzer configuration tool. Most of the configuration
items are straightforward, such as the MAC address of
the device. The following items are used to configure
the size and performance of the Stack itself. Depending
on the selected device type, not all of these options will
be available.
If the application receives messages requesting APS
level Acknowledgement, the Stack will automatically
generate and send the Acknowledge.
MAX FRAMES FROM APL LAYER
Like the APL layer frames, these must be buffered for
transmission in case of failure. Enter the number of
APS level Acknowledge frames that may be buffered
concurrently. The Stack requires two bytes of RAM for
each frame. Additional heap space will also be
allocated when a frame is generated.
Every message sent down from the APL layer using the
APSDE_DATA_request primitive must be buffered so
it can be retransmitted on failure. Additional information
must also be stored so the message confirmation can
be sent back to the APL layer via the
APSDE_DATA_confirm primitive. The Stack requires
2 bytes of RAM for each frame. Additional heap space
will also be allocated when a message is sent down.
DS01232A-page 32
© 2008 Microchip Technology Inc.
AN1232
MAX APS ADDRESSES
MAX NUMBER OF GROUPS
Although all normal messaging between nodes is done
using 16-bit network addresses, the ZigBee protocol
specification allows the APSDE_DATA_request primitive to be invoked with a 64-bit MAC address as the
message destination. If so, the APS layer searches an
APS address map for the 16-bit address of the specified
node. This table is stored in nonvolatile memory and
must be maintained by the application. Use of this table
is optional. If this value is set to ‘0’, the table is not
created; no code is created to search the table and
APSDE_DATA_request calls with 64-bit addressing will
fail. If this value is not set to ‘0’, the Stack requires
10 bytes of nonvolatile memory for each entry, plus
2 bytes of RAM.
If the device supports Group Addressing, then it must
have a Group Table. This parameter governs the maximum number of records that the Group Table will support. The stack requires 22 bytes of nonvolatile
memory for each Group Table entry.
MAX BUFFERED INDIRECT MESSAGES
If a device supports bindings (ZigBee protocol coordinators, and optionally, ZigBee protocol routers), then it
must buffer all received indirect transmissions so they
can be forwarded to one or more destinations. The
Stack requires 2 bytes of RAM for each message
specified. Additional heap space will also be allocated
when an indirect message is received.
BINDING TABLE SIZE
If a device supports bindings, then it must possess a
binding table. The Stack requires 5 bytes of nonvolatile
memory for each binding table entry. Note that the minimum binding table size is dictated by the Stack profile.
NEIGHBOR TABLE SIZE
All devices keep track of other nodes on the network by
using a Neighbor Table. End devices require a Neighbor Table to record potential parents. ZigBee protocol
coordinators require a Neighbor Table to record children. ZigBee protocol routers require a Neighbor Table
for both functions. The Stack requires 15 bytes of nonvolatile memory for each Neighbor Table entry. Note
that minimum Neighbor Table size is dictated by the
Stack profile.
MAX BUFFERED BROADCAST MESSAGES
When FFDs generate or receive a broadcast message,
they must buffer the message while they check for passive Acknowledges in case they must rebroadcast the
message. The Stack may be configured as to how many
broadcast messages may be buffered in the system at
one time. It is recommended that this value be at least
two, since a typical discovery sequence is a broadcast
NWK_ADDR_req, followed soon by a broadcast route
request. The system requires 2 bytes of RAM for each
buffered broadcast message specified. Additional heap
space will also be allocated when a broadcast message
is received or generated.
© 2008 Microchip Technology Inc.
MAX END POINTS PER GROUP
If the device supports Group Addressing, then each
Group ID can be associated with up to this many
endpoints.
MAX NUMBER OF DUPLICATE PACKETS
All devices keep track of each packet they receive. Individual packets are distinguished from each other by
their unique sequence number. If two packets are the
received that bear the same sequence number, the
second packet is tagged as a duplicate and is discarded. The number of packet sequence numbers that
are maintained and checked against the latest packet
received is governed by the parameter.
DUPLICATE TABLE EXPIRATION
This parameter governs how long a packet sequence
number is maintained by the device before the
sequence number is discarded. If two packets are
received that bear the same sequence number before
the first sequence number has expired, the second
packet is tagged as a duplicate and discarded. The
expiration time interval for the duplicate packet is
governed by this parameter.
ROUTE DISCOVERY TABLE SIZE
The ZigBee protocol specification requires that FFDs
use a route discovery table during the route discovery
process. Since these entries are required for only a
short time, they are stored in heap memory. The
system requires 2 bytes of RAM for each table entry
specified. Additional heap space will also be allocated
when route discovery is underway. Note that the minimum route discovery table size is dictated by the Stack
profile.
ROUTING TABLE SIZE
The ZigBee protocol specification requires that FFDs
maintain a routing table to route messages to other
nodes in the network. The system requires 5 bytes of
nonvolatile memory for each entry specified. Note that
the minimum routing table size is dictated by the Stack
profile.
RESERVED ROUTING TABLE ENTRIES
The ZigBee protocol specification requires that FFDs
reserve a portion of the routing table for use during
route repair. Note that the minimum reserved table
entries are dictated by the Stack profile.
DS01232A-page 33
AN1232
MAX BUFFERED ROUTING MESSAGES
If an FFD receives a message that needs to be routed,
and the FFD does not have a route for the required
destination, it must buffer the received message and
perform route discovery (if possible) for the required
destination. The system requires 10 bytes of RAM for
each buffered message specified. Additional heap
space will also be allocated when a message is
received.
CHANNEL ENERGY THRESHOLD
When a ZigBee protocol coordinator selects a channel
for a new network, it first scans all of the available channels and eliminates those whose channel energy
exceeds a specified limit.
MINIMUM JOIN LQI
When a ZigBee protocol router or end device joins a
new network, it examines the link quality of the beacon
it received from each possible parent. If the link quality
is below this specified minimum, the device will
eliminate that device as a potential parent.
TRANSACTION PERSISTENCE
ZigBee protocol coordinators and routers are required
to buffer messages for their children whose transceivers are off when they are Idle. This parameter is the
amount of time in seconds that the parent device must
buffer the messages before it may discard them.
SECURITY MODE
This parameter specifies the use of either Residential
or Commercial Security mode, as defined in the ZigBee
protocol. The differences between these modes in discussed in “Secure Transmission”. Currently, the
Microchip Stack for the ZigBee Protocol supports only
Residential mode.
TRUST CENTER
The ZigBee protocol defines the concept of a Trust
Center to coordinate the operations related to security.
A trust center must be an FFD, and there can be only
one trust center in a network. The Trust Center address
must be defined in the Coordinator as well as in the
device defined as the Trust Center.
KEY PRESENT IN ALL DEVICES ON THE
NETWORK
This parameter is used for Coordinator and Router. If
the key is present in all devices on the network, then all
devices must contain the Network Key. By defining this
parameter, it is assumed that all devices already have
the key before joining the network. As a result, the trust
center sends the joining device a dummy key, and all
packets between devices on the network may be
encrypted. If, however, this parameter is not set, the
trust center tries to send the joining device the
unprotected security key through the joining device’s
parent.
NONVOLATILE STORAGE
The ZigBee protocol requires that many tables be
stored in nonvolatile memory. PIC microcontrollers with
an allowable erase block size (smaller than 127 for
PIC18F devices) may store these in internal program
memory. This is the preferred location, since read and
write accesses are relatively fast. However, PIC MCU
devices with large erase block sizes, such as the
PIC24F devices, must store these values externally.
The Stack provides support to use an external SPI
serial EEPROM to store these values. Since some
transceivers require a dedicated SPI peripheral unless
external hardware is provided, the SPI selection may
be disabled depending on transceiver configuration.
When using external nonvolatile memory, it may be
desirable to place each device’s MAC address in the
serial EEPROM during production rather than using
SQTP when programming the PIC MCU. If the MAC
address is to be programmed into the serial EEPROM
during the manufacturing process, it should be stored
in locations 0 through 7 in the serial EEPROM.
Note:
If the application is to use security and
store its nonvolatile information externally,
the security keys will be stored in the serial
EEPROM. The Stack will encrypt these
keys before storing them, using a random
key generated by the Stack configuration
tool. Unencrypted keys will not be stored
externally.
NETWORK KEY
This parameter specifies the 16 byte network security
key. This key is used to secure the outgoing packets as
well as to decrypt the incoming packets when security
is used in Residential mode. There is also a sequence
number for the key, used primarily to identify the key,
especially if multiple network keys are transferred and
used during run time. The Network Key must be present for Coordinators and the device that acts as the
trust center.
DS01232A-page 34
© 2008 Microchip Technology Inc.
AN1232
HEAP SIZE
STACK SIZE (PIC18)
The Microchip Stack uses dynamic memory allocation for
many purposes, including those listed in Table 15. RFD
end devices may be able to have as little as one bank of
heap space. FFDs should have as much space as possible. FFDs with child devices whose transceivers are off
when Idle are required to be able to buffer one or more
messages for each child. Refer to the appropriate Stack
profile for the exact requirement. Heap space will also be
required based on the settings above. The selected heap
size should take all of these items into consideration,
and, therefore, is very application dependent.
The Microchip Stack requires only one bank of stack
space. If your application requires more, the ZENA software can generate the appropriate linker script; however, be sure to change the project’s memory model to
use a multi-bank stack. In MPLAB IDE, select
Project>Build Options>Project from the menu bar. At
the Project dialog, select the MPLAB C18 tab. Change
Category to Memory Model and select the appropriate
Stack Model.
TABLE 15:
HEAP USAGE
Description
Checking for descriptor matching
Layer
ZigBee™
Protocol
Coordinator
ZigBee
Protocol
Router
FFD End
Device
RFD End
Device
ZDO
X
X
X
X
(1)
X
X
Checking for end device bind matching
ZDO
X
Buffering messages received from the APL
APS
X
X
X
Buffering received indirect messages for retransmission
APS
X
X(1)
Buffering route requests for rebroadcast
NWK
X
X
X
X
X
Buffering other broadcast messages for rebroadcast
NWK
X
Buffering channel information on network formation
NWK
X
Buffering network information on network join
NWK
X
X
Route discovery table entries
NWK
X
X
X
Buffering messages that require routing
NWK
X
X
X
Buffering messages for RFD children in Sleep
MAC
X
X
X
Buffering a received message
PHY
X
X
X
X
Nonvolatile memory manipulation
NVM
X
X
X
X
Temporary security data during encryption process
SEC
X
X
X
X
Note 1:
If binding is supported.
LINKER SCRIPTS
The ZENA software generates linker scripts for a small
subset of devices. To modify the generated linker script
for a different device, change the following items:
FILES [device].lib – Change this to the required
device name.
CODEPAGE Sections – Change these to match those
of the required device and environment (MPLAB ICD 2
or production release build).
HEAP Area – Make sure there is enough room on the
required device for the heap size specified. DO NOT
MODIFY the START or END parameters of this section.
If the size of the heap needs to be changed, regenerate
all Stack configuration files using the ZENA software.
RX_BUFFER – Make sure this section is specified. DO
NOT MODIFY the START or END parameters of this
section.
Other DATABANK Sections – Make sure to copy the
SFR and debug areas (if needed) of the required device.
ACCESSBANK Sections – Change these to match
those of the required device.
© 2008 Microchip Technology Inc.
DS01232A-page 35
AN1232
ZigBee Protocol Timing
CONCLUSION
The data rate for 2.4 GHz operation is 250 kbps. Four
data bits are transferred during each symbol period. A
symbol period is, therefore, 16 microseconds. Internal
Stack timing is based off of the symbol period.
The Microchip Stack for the ZigBee Protocol provides a
modular, easy-to-use library that is application and
RTOS independent. It is specifically designed to support more than one RF transceiver with minimal
changes to upper layer software. Applications can be
easily ported from one RF transceiver to another. It is
targeted for the MPLAB C Compiler for PIC18 MCUs
and MPLAB C Compiler for PIC24 MCUs and dsPIC®
DSCs, but it can be easily modified to support other
compilers.
Both beacon and non-beacon networks have timings
that are based off superframes, even though the superframe is not used in non-beacon networks. The superframe duration (aBaseSuperframeDuration) is the
number of symbols that form a superframe slot
(aBaseSlotDuration, 60) multiplied by the number of
slots contained in a superframe (aNumSuperframeSlots,
16).
The
scan
duration
required
by the
NLME_NETWORK_DISCOVERY_request,
NLME_NETWORK_FORMATION_request,
and
NLME_JOIN_request primitives is (aBaseSuperframeDuration * (2n + 1)) symbols, where n is the value of the
ScanDuration parameter. For the Microchip Stack,
ScanDuration can be between 0 and 14, making the
scan time between 0.031 seconds and 4.2 minutes.
For other frequency bands, refer to the IEEE specifications for the data rate. The other times can be calculated
from that.
PIC18FJ Family Microcontroller
Considerations
Microchip ZigBee Stack version 1.0-3.8 introduced the
capability of using the ZigBee protocol Stack with
PIC18FJ devices. Due to the large program memory
erase block, the ZigBee protocol nonvolatile tables must
be stored in an external serial EEPROM with an SPI
interface. The Stack configuration tool in the ZENA Wireless Network Analyzer software may be used to configure the interface to the serial EEPROM. Table 16 lists the
hardware resources required in the demo projects for
PIC18FJ microcontroller family to use the ZigBee Stack.
TABLE 16:
• “ZigBee™ Protocol Specification”
http://www.zigbee.org
• “PICDEM™ Z Demonstration Kit User’s Guide”
(DS51524)
http://www.microchip.com
• “IEEE 802.15.4™ Specification”
http://www.ieee.org
• “ZENA™ Wireless Network Analyzer User’s
Guide” (DS51506)
http://www.microchip.com
SOURCE CODE
The complete source code, including demo applications, is available for download as a single archive file
from the Microchip corporate web site at:
www.microchip.com/wireless
PIC18FJ MICROCONTROLLER
RESOURCES REQUIRED BY
ZigBee™ STACK
Resource
INT0
REFERENCES
Description
Used to accept interrupt from MRF24J40
transceiver
TMR0
Used for symbol timer
RC0
Chip selection for MRF24J40
RC1
Voltage regulator/wake pin
RC2
Transceiver reset
RC3
SCK for MRF24J40
RC4
SDI for MRF24J40
RC5
SDO for MRF24J40
RD0
Chip selection for external EEPROM
RD3
SCK for external EEPROM
RD4
SDI for external EEPROM
RD5
SDO for external EEPROM
DS01232A-page 36
© 2008 Microchip Technology Inc.
AN1232
ANSWERS TO FREQUENTLY ASKED
QUESTIONS (FAQs)
Q: Is the Microchip Stack for the ZigBee Protocol a
ZigBee protocol compliant platform?
A: Yes.
Q: I want to use a wireless protocol, but I do not
want all of the ZigBee protocol features. May I
modify the Microchip Stack for my own use
without receiving any further permissions?
A: No. Microchip has the relevant license rights to
distribute this Stack. However, you must be a
member of the Zigbee Alliance and have a
current license to the Microchip Stack for the ZigBee Protocol in order to distribute products using
the Microchip Stack. Neither Zigbee Alliance nor
Microchip allows modifications to be made to the
Microchip Stack.
Q: How do I get the source code for the Microchip
Stack for the ZigBee Protocol?
A: You may download it from the Microchip web site
(www.microchip.com/wireless).
Q: How do I get target hardware design files?
A: You may download it from the PICDEM™ Z
Demonstration Kit page on the Microchip web
site.
Q: What tools do I need to develop a ZigBee
protocol application using the Microchip Stack?
A: You would need:
• At least one PICDEM Z demo kit or at least
two of your own ZigBee protocol nodes, or at
least two Explorer 16 boards
• Complete source code for the Microchip Stack
for the ZigBee Protocol for PIC18 and PIC24
branded products (free of charge)
• The MPLAB C Compiler for PIC18 MCUs or
MPLAB C Compiler for PIC24 MCUs and
dsPIC® DSCs
• MPLAB IDE software
• A device debugger and programmer, such as
MPLAB ICD 2
Q: What is the minimum processor clock requirement
for running the different devices?
A: Normally, ZigBee protocol coordinators and
routers should run at higher speeds as they must
be prepared to handle packets from multiple
nodes. The required clock speed depends on the
number of nodes in the network, the types of
nodes and the frequency at which the end
devices request data. The demo coordinator
uses 16 MHz (4 MHz with 4x PLL) and can
support multiple child devices. We have not
performed extensive characterization, since
there are so many possible configurations. An
end device does not have to run as fast as a
coordinator or router. A simple end device may
run at just 4 MHz.
Q: Can I use the internal RC oscillator to run the
Microchip Stack?
A: Yes, you may use the internal RC oscillator to
run the Microchip Stack. If your application
requires a stable clock to perform time-sensitive
operations, you must make sure that the internal
RC oscillator meets your requirement or you may
periodically calibrate the internal RC oscillator to
keep it within your desired range.
Q: What is the typical radio range for PICDEM Z
demo boards?
A: The exact radio range depends on the type of RF
transceiver and the type of antenna in use. A
2.4 GHz-based node with a well designed
antenna could reach as high as 100 meters lineof-sight. When placed inside a building, the
typical internal range is about 30 meters, but the
actual range may be greatly reduced due to
walls and other structural barriers.
Q: How much program and data memory does a
typical ZigBee protocol node require?
A: The exact program and data memory requirements depend on the type of node selected. In
addition, the sizes may change as new features
and improvements are added. Please refer to
the Readme file for more detail.
© 2008 Microchip Technology Inc.
DS01232A-page 37
AN1232
Q: I have an existing application that uses a wired
protocol, such as RS-232, RS-485, etc. How do
I convert it to a ZigBee protocol-based
application?
A: First, you would need to match your application
with one of the ZigBee public profiles. If no public
profile is appropriate, you would have to create
your own private profile.
If your network is relatively small, the Microchip
MiWi™ protocol provides an alternative. (For
more information, see AN1066, “MiWi™ Wireless
Networking Protocol Stack”.)
You would need to develop one ZigBee protocol
coordinator and one more ZigBee protocol enddevice application. The coordinator is required to
create and manage a network. If your existing network has one main controller and multiple end
devices or sensor devices, your main controller
would become a ZigBee protocol coordinator and
sensor devices would become ZigBee protocol
end devices. If the existing devices are already
mains powered, you may want to consider
making the end devices FFDs rather than RFDs.
FFDs do not generate as much network traffic and
can easily be converted to routers in case one or
more of your devices is out of radio range of the
coordinator. You must make sure that the radio
range offered by a specific RF transceiver is
acceptable to your application.
Q: How do I obtain the ZigBee protocol and
IEEE 802.15.4 specification documents?
A: Both specifications are freely available on the
internet. The IEEE 802.15.4 specification
is
available at http://standards.ieee.org/
getieee802/download/802.15.4-2003.pdf. The
ZigBee protocol specification is available at
www.zigbee.org.
Q: I have an application that I have built with an
earlier version of the Microchip Stack. How do I
port my application to the new Stack?
A: The interface to the v2.0-2.6 Stack architecture
is the same as v1.0-3.8 with the exception of the
KVP message format which was eliminated.
Study the template file for the device type you
need. The places to insert application-specific
code are indicated by large comment blocks:
• Messages Received for User-Defined
Endpoints: The new architecture handles
endpoints differently. There is no need to
“open” or “close” an endpoint. Each endpoint
is simply a case of a switch statement. Note
that the APLDiscardRx() function is called
after the switch statement, so the individual
endpoints do not need to call it.
• Application Processing that can Generate
ZigBee Protocol Messages: A new outgoing
message can only be started if the current
primitive is NO_PRIMITIVE and another
outgoing message is not already waiting
(ZigBeeReady() returns TRUE). Place all
message generation processing from all endpoints here. Note that no code is required to
retry the message in case it fails to transmit or
receive an APS level Acknowledge. That is
now handled automatically by the Stack. Also,
the Stack now automatically handles all
message routing.
• Non-Related ZigBee Protocol Processing:
If the application has any other processing
that does not relate at all to the ZigBee protocol, place that code here. Make sure that this
processing does not lock the system for long
periods of time or the Stack will miss incoming
messages.
• Hardware Initialization: The required
hardware initialization for the PICDEM Z
demo board is included in the template files. If
your hardware requirements are different,
modify this function appropriately. Note that
this function must properly configure all pins
required to interface with the transceiver and
must be called before ZigBeeInit().
Network formation and association are provided by the
sample applications.
• Application-Specific Initialization: Insert
any initialization required by the application
before the Stack is started.
• Received ZDO Responses: Insert code here
to handle responses to ZDO requests that the
application issues. If the application does not
issue any ZDO requests, this section will be
empty.
DS01232A-page 38
© 2008 Microchip Technology Inc.
AN1232
REVISION HISTORY
Rev A Document (10/2008)
Original version of this document.
© 2008 Microchip Technology Inc.
DS01232A-page 39
AN1232
NOTES:
DS01232A-page 40
© 2008 Microchip Technology Inc.
Note the following details of the code protection feature on Microchip devices:
•
Microchip products meet the specification contained in their particular Microchip Data Sheet.
•
Microchip believes that its family of products is one of the most secure families of its kind on the market today, when used in the
intended manner and under normal conditions.
•
There are dishonest and possibly illegal methods used to breach the code protection feature. All of these methods, to our
knowledge, require using the Microchip products in a manner outside the operating specifications contained in Microchip’s Data
Sheets. Most likely, the person doing so is engaged in theft of intellectual property.
•
Microchip is willing to work with the customer who is concerned about the integrity of their code.
•
Neither Microchip nor any other semiconductor manufacturer can guarantee the security of their code. Code protection does not
mean that we are guaranteeing the product as “unbreakable.”
Code protection is constantly evolving. We at Microchip are committed to continuously improving the code protection features of our
products. Attempts to break Microchip’s code protection feature may be a violation of the Digital Millennium Copyright Act. If such acts
allow unauthorized access to your software or other copyrighted work, you may have a right to sue for relief under that Act.
Information contained in this publication regarding device
applications and the like is provided only for your convenience
and may be superseded by updates. It is your responsibility to
ensure that your application meets with your specifications.
MICROCHIP MAKES NO REPRESENTATIONS OR
WARRANTIES OF ANY KIND WHETHER EXPRESS OR
IMPLIED, WRITTEN OR ORAL, STATUTORY OR
OTHERWISE, RELATED TO THE INFORMATION,
INCLUDING BUT NOT LIMITED TO ITS CONDITION,
QUALITY, PERFORMANCE, MERCHANTABILITY OR
FITNESS FOR PURPOSE. Microchip disclaims all liability
arising from this information and its use. Use of Microchip
devices in life support and/or safety applications is entirely at
the buyer’s risk, and the buyer agrees to defend, indemnify and
hold harmless Microchip from any and all damages, claims,
suits, or expenses resulting from such use. No licenses are
conveyed, implicitly or otherwise, under any Microchip
intellectual property rights.
Trademarks
The Microchip name and logo, the Microchip logo, Accuron,
dsPIC, KEELOQ, KEELOQ logo, MPLAB, PIC, PICmicro,
PICSTART, rfPIC, SmartShunt and UNI/O are registered
trademarks of Microchip Technology Incorporated in the
U.S.A. and other countries.
FilterLab, Linear Active Thermistor, MXDEV, MXLAB,
SEEVAL, SmartSensor and The Embedded Control Solutions
Company are registered trademarks of Microchip Technology
Incorporated in the U.S.A.
Analog-for-the-Digital Age, Application Maestro, CodeGuard,
dsPICDEM, dsPICDEM.net, dsPICworks, dsSPEAK, ECAN,
ECONOMONITOR, FanSense, In-Circuit Serial
Programming, ICSP, ICEPIC, Mindi, MiWi, MPASM, MPLAB
Certified logo, MPLIB, MPLINK, mTouch, PICkit, PICDEM,
PICDEM.net, PICtail, PIC32 logo, PowerCal, PowerInfo,
PowerMate, PowerTool, REAL ICE, rfLAB, Select Mode, Total
Endurance, WiperLock and ZENA are trademarks of
Microchip Technology Incorporated in the U.S.A. and other
countries.
SQTP is a service mark of Microchip Technology Incorporated
in the U.S.A.
All other trademarks mentioned herein are property of their
respective companies.
© 2008, Microchip Technology Incorporated, Printed in the
U.S.A., All Rights Reserved.
Printed on recycled paper.
Microchip received ISO/TS-16949:2002 certification for its worldwide
headquarters, design and wafer fabrication facilities in Chandler and
Tempe, Arizona; Gresham, Oregon and design centers in California
and India. The Company’s quality system processes and procedures
are for its PIC® MCUs and dsPIC® DSCs, KEELOQ® code hopping
devices, Serial EEPROMs, microperipherals, nonvolatile memory and
analog products. In addition, Microchip’s quality system for the design
and manufacture of development systems is ISO 9001:2000 certified.
© 2008 Microchip Technology Inc.
DS01232A-page 41
WORLDWIDE SALES AND SERVICE
AMERICAS
ASIA/PACIFIC
ASIA/PACIFIC
EUROPE
Corporate Office
2355 West Chandler Blvd.
Chandler, AZ 85224-6199
Tel: 480-792-7200
Fax: 480-792-7277
Technical Support:
http://support.microchip.com
Web Address:
www.microchip.com
Asia Pacific Office
Suites 3707-14, 37th Floor
Tower 6, The Gateway
Harbour City, Kowloon
Hong Kong
Tel: 852-2401-1200
Fax: 852-2401-3431
India - Bangalore
Tel: 91-80-4182-8400
Fax: 91-80-4182-8422
India - New Delhi
Tel: 91-11-4160-8631
Fax: 91-11-4160-8632
Austria - Wels
Tel: 43-7242-2244-39
Fax: 43-7242-2244-393
Denmark - Copenhagen
Tel: 45-4450-2828
Fax: 45-4485-2829
India - Pune
Tel: 91-20-2566-1512
Fax: 91-20-2566-1513
France - Paris
Tel: 33-1-69-53-63-20
Fax: 33-1-69-30-90-79
Japan - Yokohama
Tel: 81-45-471- 6166
Fax: 81-45-471-6122
Germany - Munich
Tel: 49-89-627-144-0
Fax: 49-89-627-144-44
Atlanta
Duluth, GA
Tel: 678-957-9614
Fax: 678-957-1455
Boston
Westborough, MA
Tel: 774-760-0087
Fax: 774-760-0088
Chicago
Itasca, IL
Tel: 630-285-0071
Fax: 630-285-0075
Dallas
Addison, TX
Tel: 972-818-7423
Fax: 972-818-2924
Detroit
Farmington Hills, MI
Tel: 248-538-2250
Fax: 248-538-2260
Kokomo
Kokomo, IN
Tel: 765-864-8360
Fax: 765-864-8387
Los Angeles
Mission Viejo, CA
Tel: 949-462-9523
Fax: 949-462-9608
Santa Clara
Santa Clara, CA
Tel: 408-961-6444
Fax: 408-961-6445
Toronto
Mississauga, Ontario,
Canada
Tel: 905-673-0699
Fax: 905-673-6509
Australia - Sydney
Tel: 61-2-9868-6733
Fax: 61-2-9868-6755
China - Beijing
Tel: 86-10-8528-2100
Fax: 86-10-8528-2104
China - Chengdu
Tel: 86-28-8665-5511
Fax: 86-28-8665-7889
Korea - Daegu
Tel: 82-53-744-4301
Fax: 82-53-744-4302
China - Hong Kong SAR
Tel: 852-2401-1200
Fax: 852-2401-3431
Korea - Seoul
Tel: 82-2-554-7200
Fax: 82-2-558-5932 or
82-2-558-5934
China - Nanjing
Tel: 86-25-8473-2460
Fax: 86-25-8473-2470
Malaysia - Kuala Lumpur
Tel: 60-3-6201-9857
Fax: 60-3-6201-9859
China - Qingdao
Tel: 86-532-8502-7355
Fax: 86-532-8502-7205
Malaysia - Penang
Tel: 60-4-227-8870
Fax: 60-4-227-4068
China - Shanghai
Tel: 86-21-5407-5533
Fax: 86-21-5407-5066
Philippines - Manila
Tel: 63-2-634-9065
Fax: 63-2-634-9069
China - Shenyang
Tel: 86-24-2334-2829
Fax: 86-24-2334-2393
Singapore
Tel: 65-6334-8870
Fax: 65-6334-8850
China - Shenzhen
Tel: 86-755-8203-2660
Fax: 86-755-8203-1760
Taiwan - Hsin Chu
Tel: 886-3-572-9526
Fax: 886-3-572-6459
China - Wuhan
Tel: 86-27-5980-5300
Fax: 86-27-5980-5118
Taiwan - Kaohsiung
Tel: 886-7-536-4818
Fax: 886-7-536-4803
China - Xiamen
Tel: 86-592-2388138
Fax: 86-592-2388130
Taiwan - Taipei
Tel: 886-2-2500-6610
Fax: 886-2-2508-0102
China - Xian
Tel: 86-29-8833-7252
Fax: 86-29-8833-7256
Thailand - Bangkok
Tel: 66-2-694-1351
Fax: 66-2-694-1350
Italy - Milan
Tel: 39-0331-742611
Fax: 39-0331-466781
Netherlands - Drunen
Tel: 31-416-690399
Fax: 31-416-690340
Spain - Madrid
Tel: 34-91-708-08-90
Fax: 34-91-708-08-91
UK - Wokingham
Tel: 44-118-921-5869
Fax: 44-118-921-5820
China - Zhuhai
Tel: 86-756-3210040
Fax: 86-756-3210049
01/02/08
DS01232A-page 42
© 2008 Microchip Technology Inc.
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement