SN260
ZigBee 802.15.4 network processor
Features
Integrated 2.4GHz, IEEE 802.15.4-compliant transceiver: Robust RX filtering allows co-existence with IEEE 802.11g and Bluetooth devices - 97.5dBm RX sensitivity (1% PER, 20byte packet) + 3dBm nominal output power Increased radio performance mode (boost mode) gives 98.5dBm sensitivity and +5dBm transmit power Integrated VCO and loop filter Secondary TX-only RF port for applications requiring external PA. Integrated IEEE 802.15.4 PHY and MAC Dedicated peripherals and integrated memory EmberZNetTM ZigBee-compliant stack running on the dedicated network processor
Controlled by the Host using the EmberZNetTM Serial Protocol (EZSP) Standard serial interface (allows for connection to a variety of Host micro controllers) Non-intrusive debug interface (SIF) Integrated hardware and software support for InSightTM Development Environment Provides integrated RC oscillator for low power operation Three sleep modes: Processor idle (automatic) Deep sleep--1.0A Power down--1.0A Watchdog timer and power-on-reset circuitry Integrated AES encryption accelerator Integrated 1.8V voltage regulator Compatible with Ember EM250
TX_ACTIVE
PA select
RF_TX_ALT_P,N
PA SYNTH PA DAC MAC + Baseband
PacketTrace
RF_P,N BIAS_R OSCA OSCB
LNA Bias HF OSC
IF
ADC
Network Processor (XAP2b)
Encryption acclerator
Network Processor Peripherals Integrated Flash and RAM
Internal RC-OSC
Serial Controller
Interrupt Controller
Always powered Sleep timer Watchdog
POR
nRESET SIF_CLK
SIF
VREG_OUT
Regulator Chip manager
IO Controller
SIF_MISO SIF_MOSI nSIF_LOAD
nSSEL_INT
nSSEL
SCLK
MISO
MOSI
nWAKE
nHOST_INT
LINK_ACTIVITY
PTI_DATA
April 2008
Rev 3
PTI_EN
SDBG
1/88
www.st.com 1
Contents
SN260
Contents
1 2 3 4 General description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Pin assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Top-level functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Electrical characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1 4.2 4.3 4.4 4.5 4.6 Absolute maximum ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Recommended operating conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Environmental characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 DC electrical characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Digital I/O specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 RF electrical characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.6.1 4.6.2 4.6.3 Receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Transmit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Synthesizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5
Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1 Receive (RX) path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1.1 5.1.2 RX baseband . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 RSSI and CCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2
Transmit (TX) path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2.1 5.2.2 TX baseband . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 TX_ACTIVE signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3 5.4 5.5 5.6
Integrated MAC module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Packet trace interface (PTI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 16-bit microprocessor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Embedded memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.6.1 5.6.2 Simulated EEPROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Flash information area (FIA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.7 5.8 5.9
Encryption accelerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Reset detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Power-on-reset (POR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2/88
SN260
Contents
5.10
Clock sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.10.1 5.10.2 High-frequency crystal oscillator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Internal RC oscillator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.11 5.12 5.13 5.14
Random number generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Watchdog timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Sleep timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Power management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6
SPI protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.1 6.2 Physical interface configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 SPI transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2.1 6.2.2 6.2.3 6.2.4 6.2.5 6.2.6 6.2.7 Command section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Wait section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Response section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Asynchronous signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Spacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Waking the SN260 from sleep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Error conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.3 6.4 6.5
SPI protocol timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Data format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 SPI byte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.5.1 6.5.2 Primar y SPI bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Special response bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.6 6.7
Powering on, power cycling, and rebooting . . . . . . . . . . . . . . . . . . . . . . . 29
6.6.1 Unexpected resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Transaction examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.7.1 6.7.2 6.7.3 6.7.4 SPI protocol version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 EmberZNet serial protocol frame -- NOP command . . . . . . . . . . . . . . . 30 SN260 reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Three-par t transaction: Wake, Get Version, Stack Status Callback . . . . 32
7
EmberZNet serial protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.1 7.2 Byte order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Conceptual overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.2.1 7.2.2 Stack configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Policy settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3/88
Contents 7.2.3 7.2.4 7.2.5 7.2.6 7.2.7 7.2.8 7.2.9
SN260 Datagram replies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Callbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Power management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 SN260 status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Random number generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.3
Protocol format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.3.1 7.3.2 7.3.3 7.3.4 7.3.5 7.3.6 7.3.7 7.3.8 7.3.9 Type definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Structure definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Named values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Configuration frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Utilities frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Networking frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Binding frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Messaging frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Alphabetical list of frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.4
Sample transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
7.4.1 7.4.2 7.4.3 7.4.4 Joining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Sending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Receiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
8 9 10 11 12 13 14
SIF module programming and debug interface . . . . . . . . . . . . . . . . . . 81 Typical application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Mechanical details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Ordering information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4/88
SN260
General description
1
General description
The SN260 integrates a 2.4GHz, IEEE 802.15.4-compliant transceiver with a 16-bit network processor (XAP2b core) to run EmberZNetTM, the ZigBee-compliant network stack. The SN260 exposes access to the EmberZNet API across a standard SPI module, allowing application development on a Host processor. This means that the SN260 can be viewed as a ZigBee peripheral connected over a SPI. The XAP2b microprocessor is a power-optimized core integrated in the SN260. It contains integrated Flash and RAM memory along with an optimized peripheral set to enhance the operation of the network stack. The transceiver utilizes an efficient architecture that exceeds the dynamic range requirements imposed by the IEEE 802.15.4-2003 standard by over 15dB. The integrated receive channel filtering allows for co-existence with other communication standards in the 2.4GHz spectrum such as IEEE 802.11g and Bluetooth. The integrated regulator, VCO, loop filter, and power amplifier keep the external component count low. An optional highperformance radio mode (boost mode) is software selectable to boost dynamic range by a further 3dB. The SN260 contains embedded Flash and integrated RAM for program and data storage. By employing an effective wear-leveling algorithm, the stack optimizes the lifetime of the embedded Flash, and affords the application the ability to configure stack and application tokens within the SN260. To maintain the strict timing requirements imposed by ZigBee and the IEEE 802.15.4-2003 standard, the SN260 integrates a number of MAC functions into the hardware. The MAC hardware handles automatic ACK transmission and reception, automatic backoff delay, and clear channel assessment for transmission, as well as automatic filtering of received packets. In addition, the SN260 allows for true MAC level debugging by integrating the Packet Trace Interface. An integrated voltage regulator, power-on-reset circuitry, sleep timer, and low-power sleep modes are available. The deep sleep and power down modes draws less than 1 A, allowing products to achieve long battery life. Finally, the SN260 utilizes the non-intrusive SIF module for powerful software debugging and programming of the network processor. Target applications for the SN260 include:
Building automation and control Home automation and control Home entertainment control Asset tracking
The SN260 can only be purchased with the EmberZNet stack. This technical datasheet details the SN260 features available to customers using it with the EmberZNet stack.
5/88
Pin assignment
SN260
2
Pin assignment
Figure 1. SN260 pin assignment
VDD_SYNTH_PRE
LINK_ACTIVITY
VDD_24MHZ
VDD_FLASH 32
VDD_CORE
nWAKE
OSCA
OSCB
SDBG
40 VDD_VCO RF_P RF_N VDD_RF RF_TX_ALT_P RF_TX_ALT_N VDD_IF BIAS_R VDD_PADSA TX_ACTIVE 1 2 3 4 5 6 7 8 9 10 11
39
38
37
36
35
34
33
GND 31 30 29 28 27 nSIF_LOAD SIF_MOSI SIF_MISO SIF_CLK nHOST_INT RES VDD_PADS PTI_DATA PTI_EN nSSEL 26 25 24 23 22 21 20 SCLK
41 GND
EM260
SN260
12
13
14
15
16
17
18
19
VDD_CORE
VDD_PADS
RES
VREG_OUT
Table 1.
Pin # 1 2 3 4 5 6 7 8 9 10
Pin descriptions
Signal VDD_VCO RF_P RF_N VDD_RF RF_TX_ALT_P RF_TX_ALT_N VDD_IF BIAS_R VDD_PADSA TX_ACTIVE Direction Power I/O I/O Power O O Power I Power O 1.8V VCO supply Differential (with RF_N) receiver input/transmitter output Differential (with RF_P) receiver input/transmitter output 1.8V RF supply (LNA and PA) Differential (with RF_TX_ALT_N) transmitter output (optional) Differential (with RF_TX_ALT_P) transmitter output (optional) 1.8V IF supply (mixers and filters) Bias setting resistor Analog pad supply (1.8V) Logic-level control for external RX/TX switch The SN260 baseband controls TX_ACTIVE and drives it high (1.8V) when in TX mode. (Refer to Table 6 and section TX_ACTIVE signal.) Description
6/88
VDD_PADS
nRESET
nSSEL_INT
MISO
MOSI
SN260 Table 1.
Pin # 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41
Pin assignment Pin descriptions (continued)
Signal nRESET VREG_OUT VDD_PADS VDD_CORE nSSEL_INT RES MOSI MISO VDD_PADS SCLK nSSEL PTI_EN PTI_DATA VDD_PADS RES nHOST_INT SIF_CLK SIF_MISO SIF_MOSI nSIF_LOAD GND VDD_FLASH SDBG LINK_ACTIVITY nWAKE VDD_CORE VDD_SYNTH_PRE OSCB OSCA VDD_24MHZ GND O I O I I/O Power Power O O I Power Power I/O I/O Power Ground I O Power I I O O Power Direction I Power Power Power I Description Active low chip reset (internal pull-up) Regulator output (1.8V) Pads supply (2.1 3.6V) 1.8V digital core supply SPI Slave Select Interrupt (from Host to SN260) This signal must be connected to nSSEL (Pin 21) Reser ved for future use, do not connect to any signal. SPI Data, Master Out / Slave In (from Host to SN260) SPI Data, Master In / Slave Out (from SN260 to Host) Pads supply (2.1 3.6V) SPI Clock (from Host to SN260) SPI Slave Select (from Host to SN260) Frame signal of Packet Trace Interface (PTI) Data signal of Packet Trace Interface (PTI) Pads supply (2.1 3.6V) Reser ved for future use, do not connect to any signal. Host Interrupt signal (from SN260 to Host) Serial Interface, Clock (internal pull down) Serial Interface, Master In / Slave Out Serial Interface, Master Out / Slave In Serial Interface, load strobe (open collector with internal pull up) Ground Supply 1.8V Flash memory supply Spare Debug signal Link and Activity signal Wake Interrupt signal (from Host to SN260) 1.8V digital core supply 1.8V synthesizer and pre-scalar supply 24MHz crystal oscillator or left open for when using an external clock input on OSCA 24MHz crystal oscillator or external clock input 1.8V high-frequency oscillator supply Ground supply pad in the bottom center of the package forms Pin 41 (see the EM260 Reference Design for PCB considerations)
7/88
Top-level functional description
SN 2 6 0
3
Top-level functional description
Figure 2 shows a detailed block diagram of the SN260. Figure 2. SN260 block diagram
TX_ACTIVE
PA select
RF_TX_ALT_P,N
PA SYNTH PA DAC MAC + Baseband
PacketTrace
RF_P,N BIAS_R OS CA OS CB
LNA Bias HF OSC
IF
ADC
Network Processor (XAP2b)
Encryption acclerator
Network Processor Peripherals Integrated Flash and RAM
Internal RC-OSC
Serial Controller
Interrupt Controller
Always powered Sleep timer Watchdog
POR
nRESET SIF_CLK
S IF
VREG_OUT
Regulator Chip manager
IO Controller
SIF_ MIS O SIF_ MOS I nSIF_LOAD
nSSEL_INT
nSSEL
SCLK
MISO
MOSI
nHOST_INT
nWAKE
LINK_ACTIVITY
PTI_DATA
SDBG
The radio receiver is a low-IF, super-heterodyne receiver. It utilizes differential signal paths to minimize noise interference, and its architecture has been chosen to optimize coexistence with other devices within the 2.4GHz band (namely, IEEE 802.11g and Bluetooth). After amplification and mixing, the signal is filtered and combined prior to being sampled by an ADC. The digital receiver implements a coherent demodulator to generate a chip stream for the hardware-based MAC. In addition, the digital receiver contains the analog radio calibration routines and control of the gain within the receiver path. The radio transmitter utilizes an efficient architecture in which the data stream directly modulates the VCO. An integrated PA boosts the output power. The calibration of the TX path as well as the output power is controlled by digital logic. If the SN260 is to be used with an external PA, the TX_ACTIVE signal should be used to control the timing of the external switching logic. The integrated 4.8GHz VCO and loop filter minimize off-chip circuitry. Only a 24MHz crystal with its loading capacitors is required to properly establish the PLL reference signal. The MAC interfaces the data memory to the RX and TX baseband modules. The MAC provides hardware-based IEEE 802.15.4 packet-level filtering. It supplies an accurate symbol time base that minimizes the synchronization effort of the software stack and meets the protocol timing requirements. In addition, it provides timer and synchronization assistance for the IEEE 802.15.4 CSMA-CA algorithm.
8/88
PTI_EN
SN260
Top-level functional description The SN260 integrates hardware support for a Packet Trace module, which allows robust packet-based debug. This element is a critical component of InSightTM Desktop, the Ember software IDE, providing advanced network debug capability when coupled with the InSightTM Adapter. The SN260 integrates a 16-bit XAP2b microprocessor developed by Cambridge Consultants Ltd. This power-efficient, industry-proven core provides the appropriate level of processing power to meet the needs of the ZigBee-compliant stack, EmberZNet. In addition, the SIF module provides a non-intrusive programming and debug interface allowing for realtime application debugging. The SN260 exposes the EmberZNet Serial API over the SPI, which allows application development to occur on a Host micro controller of choice. In addition to the four SPI signals, two additional signals, nHOST_INT and nWAKE, provide an easy-to-use handshake mechanism between the Host and the SN260. The integrated voltage regulator generates a regulated 1.8V reference voltage from an unregulated supply voltage. This voltage is decoupled and routed externally to supply the 1.8V to the core logic. In addition, an integrated POR module allows for the proper cold start of the SN260. The SN260 contains one high-frequency (24MHz) crystal oscillator and, for low-power operation, a second low-frequency internal 10 kHz oscillator. The SN260 contains two power domains. The always-powered high voltage supply is used for powering the GPIO pads and critical chip functions. The rest of the chip is powered by a regulated Low Voltage Supply which can be disabled during deep sleep to reduce the power consumption.
9/88
Electrical characteristics
SN 2 6 0
4
4.1
Table 2.
Electrical characteristics
Absolute maximum ratings
Table 2 lists the absolute maximum ratings for the SN260. Absolute maximum ratings
Parameter Test conditions Min. - 0.3 - 0.3 - 0.3 Max. 3.6 2.0 3.6 Unit V V V
Regulator voltage (VDD_PADS) Core voltage (VDD_24MHZ, VDD_VCO, VDD_RF, VDD_IF, VDD_PADSA, VDD_FLASH, VDD_SYNTH_PRE, VDD_CORE) Voltage on RF_P,N; RF_TX_ALT_P,N Voltage on nSSEL_INT, MOSI, MISO, SCLK, nSSEL, PTI_EN, PTI_DATA, nHOST_INT, SIF_CLK, SIF_MISO, SIF_MOSI, nSIF_LOAD, SDBG, LINK_ACTIVITY, nWAKE, nRESET, VREG_OUT Voltage on TX_ACTIVE, BIAS_R, OSCA, OSCB Storage temperature
- 0.3
VDD_PADS+0.3
V
- 0.3 - 40
VDD_CORE+0.3 + 140
V C
4.2
Table 3.
Recommended operating conditions
Table 3 lists the rated operating conditions of the SN260. Operating conditions
Parameter Test conditions Min. 2.1 1.7 - 40 1.8 Typ. Max. 3.6 1.9 + 85 Unit V V C
Regulator input voltage (VDD_PADS) Core input voltage (VDD_24MHZ, VDD_VCO, VDD_RF, VDD_IF, VDD_PADSA, VDD_FLASH, VDD_SYNTH_PRE, VDD_CORE) Temperature range
10/88
SN260
Electrical characteristics
4.3
Table 4.
Environmental characteristics
Table 4 lists the environmental characteristics of the SN260. Environmental characteristics
Parameter Test Conditions On any pin Non-RF pins RF pins Min. -2 - 400 - 225 TBD Typ. Max. +2 + 400 + 225 Unit kV V V
ESD (human body model) ESD (charged device model) ESD (charged device model) MSL (moisture sensitivity level)
4.4
Table 5.
DC electrical characteristics
Table 5 lists the DC electrical characteristics of the SN260. DC characteristics
Parameter Test Conditions Min. 2.1 Regulator output or external input 1.7 1.8 Typ. Max. 3.6 1.9 Unit V V
Regulator input voltage (VDD_PADS) Power supply range (VDD_CORE) Deep sleep current Quiescent current, including internal RC oscillator RX current Radio receiver, MAC, and baseband (boost mode) Radio receiver, MAC, and baseband CPU, RAM, and Flash memory Total RX current ( = IRadio receiver, MAC and baseband, CPU + IRAM, and Flash memory ) TX current Radio transmitter, MAC, and baseband (boost mode) Radio transmitter, MAC, and baseband At max. TX power (+ 5dBm typical) At max. TX power (+ 3dBm typical) At 0dBm typical At min. TX power (- 32dBm typical) CPU, RAM, and Flash memory At 25 C, VDD_PADS = 3.0V At 25 C and 1.8V core At 25 C, VDD_PADS = 3.0V At 25 C
1.0
A
29.0 27.0 8.5 35.5
mA mA mA mA
33.0 27.0 24.3 19.5 8.5 35.5
mA mA mA mA mA mA
Total TX current At 25 C and 1.8V core; max. ( = IRadio transmitter, MAC and baseband, CPU + power out IRAM, and Flash memory )
11/88
Electrical characteristics
SN 2 6 0
4.5
Digital I/O specifications
Table 6 contains the digital I/O specifications for the SN260. The digital I/O power (named VDD_PADS) comes from three dedicated pins (pins 13, 19, and 24). The voltage applied to these pins sets the I/O voltage.
Table 6.
Digital I/O specifications
Parameter Name VDD_PADS VI L VI H IIL II H RIPU RIPD VOL VOH IOHS IOLS IOHH IOLH IOH + IOL 0.2 x VDD_CORE 0.18 x VDD_CORE 0 0.82 x VDD_PADS 30 30 0.18 x VDD_PADS VDD_PADS 4 4 8 8 40 0.8 x VDD_PADS 0.82 x VDD_CORE 1 Min. 2.1 0 0.8 x VDD_PADS Typ. Max. 3.6 0.2 x VDD_PADS VDD_PADS -0.5 0.5 Unit V V V A A k k V V mA mA mA mA mA V V mA
Voltage supply Input voltage for logic 0 Input voltage for logic 1 Input current for logic 0 Input current for logic 1 Input pull-up resistor value Input pull-down resistor value Output voltage for logic 0 Output voltage for logic 1 Output source current (standard current pad) Output sink current (standard current pad) Output source current (high current pad: pins 33, 34, and 35) Output sink current (high current pad: pins 33, 34, and 35) Total output current (for I/O pads) Input voltage threshold for OSCA Output voltage level (TX_ACTIVE) Output source current (TX_ACTIVE)
12/88
SN260
Electrical characteristics
4.6
4.6.1
Note:
RF electrical characteristics
Receive
Table 7 lists the key parameters of the integrated IEEE 802.15.4 receiver on the SN260. Receive measurements were collected with Ember's EM260 reference design at 2440MHz. The Typical number indicates one standard deviation above the mean. Receive characteristics
Parameter Test conditions Min. 2400 1% PER, 20byte packet defined by IEEE 802.15.4 1% PER, 20byte packet defined by IEEE 802.15.4 IEEE 802.15.4 signal at -82dBm IEEE 802.15.4 signal at - 82dBm IEEE 802.15.4 signal at - 82dBm IEEE 802.15.4 signal at - 82dBm IEEE 802.15.4 signal at - 82dBm - 93 - 92 - 98.5 - 97.5 35 35 40 40 40 40 0 30 IEEE 802.15.4 signal at - 82dBm - 120 - 120 40 -6 + 120 + 120 Typ. Max. 2500 Unit MHz dBm dBm dB dB dB dB dB dB dBm dB dBc ppm ppm dB
Table 7.
Frequency range Sensitivity (boost mode) Sensitivity High-side adjacent channel rejection Low-side adjacent channel rejection 2
nd
high-side adjacent channel rejection
2nd low-side adjacent channel rejection Channel rejection for all other channels
802.11g rejection centered at + 12MHz or IEEE 802.15.4 signal at - 82dBm - 13MHz Maximum input signal level for correct operation (low gain) Image suppression Co-channel rejection Relative frequency error (2 x 40 ppm required by IEEE 802.15.4) Relative timing error (2 x 40 ppm required by IEEE 802.15.4) Linear RSSI range
13/88
Electrical characteristics
SN 2 6 0
4.6.2
Note:
Transmit
Table 8 lists the key parameters of the integrated IEEE 802.15.4 transmitter on the SN260. Transmit measurements were collected with Ember's EM260 reference design at 2440MHz. The Typical number indicates one standard deviation below the mean. Transmit characteristics
Parameter Test conditions At highest power setting At highest power setting At lowest power setting As defined by IEEE 802.15.4, which sets a 35% maximum - 40 200 3.5MHz away 3.5MHz away - 20 - 30 dB dBm 0 Min. Typ. 5 3 - 32 15 25 + 40 Max. Unit dBm dBm dBm % ppm
Table 8.
Maximum output power (boost mode) Maximum output power Minimum output power Error vector magnitude Carrier frequency error Load impedance PSD mask relative PSD mask absolute
4.6.3
Synthesizer
Table 9 lists the key parameters of the integrated synthesizer on the SN260.
Table 9.
Parameter
Synthesizer characteristics
Test conditions Min. 2400 11.7 From off, with correct VCO DAC setting Channel change or RX/TX turnaround (IEEE 802.15.4 defines 192s turnaround time) - 71 - 91 - 103 - 111 100 100 Typ. Max. 2500 Unit MHz kHz s s dBc/Hz dBc/Hz dBc/Hz dBc/Hz
Frequency range Frequency resolution Lock time Relock time Phase noise at 100kHz Phase noise at 1MHz Phase noise at 4MHz Phase noise at 10MHz
14/88
SN260
Functional description
5
Functional description
The SN260 connects to the Host micro controller through a standard SPI interface. The EmberZNet Serial Protocol (EZSP) has been defined to allow an application to be written on a host micro controller of choice. Therefore, the SN260 comes with a license to EmberZNet, the ZigBee-compliant software stack. The following brief description of the hardware modules provides the necessary background on the operation of the SN260. For more information, contact your local ST sales representative.
5.1
Receive (RX) path
The SN260 RX path spans the analog and digital domains. The RX architecture is based on a low-IF, super-heterodyne receiver. It utilizes differential signal paths to minimize noise interference. The input RF signal is mixed down to the IF frequency of 4MHz by I and Q mixers. The output of the mixers is filtered and combined prior to being sampled by a 12Msps ADC. The RX filtering within the RX path has been designed to optimize the coexistence of the SN260 with other 2.4GHz transceivers, such as the IEEE 802.11g and Bluetooth.
5.1.1
RX baseband
The SN260 RX baseband (within the digital domain) implements a coherent demodulator for optimal performance. The baseband demodulates the O-QPSK signal at the chip level and synchronizes with the IEEE 802.15.4-2003 preamble. Once a packet preamble is detected, it de-spreads the demodulated data into 4-bit symbols. These symbols are buffered and passed to the hardware-based MAC module for filtering. In addition, the RX baseband provides the calibration and control interface to the analog RX modules, including the LNA, RX Baseband Filter, and modulation modules. The EmberZNet software includes calibration algorithms which use this interface to reduce the effects of process and temperature variation.
5.1.2
RSSI and CCA
The SN260 calculates the RSSI over an 8-symbol period as well as at the end of a received packet. It utilizes the RX gain settings and the output level of the ADC within its algorithm. The SN260 RX baseband provides support for the IEEE 802.15.4-2003 required CCA methods summarized in Table 10. Modes 1, 2, and 3 are defined by the 802.15.4-2003 standard; Mode 0 is a proprietary mode. Table 10.
CCA mode 0 1 2 3
CCA mode behavior
Mode behavior Clear channel reports busy medium if either carrier sense OR RSSI exceeds their thresholds. Clear channel reports busy medium if RSSI exceeds its threshold. Clear channel reports busy medium if carrier sense exceeds its threshold. Clear channel reports busy medium if both RSSI and carrier sense exceed their thresholds.
15/88
Functional description
SN260
5.2
Transmit (TX) path
The SN260 transmitter utilizes both analog circuitry and digital logic to produce the O-QPSK modulated signal. The area-efficient TX architecture directly modulates the spread symbols prior to transmission. The differential signal paths increase noise immunity and provide a common interface for the external balun.
5.2.1
TX baseband
The SN260 TX baseband (within the digital domain) performs the spreading of the 4-bit symbol into its IEEE 802.15.4-2003-defined 32-chip I and Q sequence. In addition, it provides the interface for software to perform the calibration of the TX module in order to reduce process, temperature, and voltage variations.
5.2.2
TX_ACTIVE signal
Even though the SN260 provides an output power suitable for most ZigBee applications, some applications will require an external power amplifier (PA). Due to the timing requirements of IEEE 802.15.4-2003, the SN250 provides a signal, TX_ACTIVE, to be used for external PA power management and RF Switching logic. When in TX, the TX Baseband drives TX_ACTIVE high (as described inTable 6). When in RX, the TX_ACTIVE signal is low. If an external PA is not required, then the TX_ACTIVE signal should be connected to GND through a 100k Ohm resistor, as shown in the application circuit in Figure 12.
5.3
Integrated MAC module
The SN260 integrates critical portions of the IEEE 802.15.4-2003 MAC requirements in hardware. This allows the SN260 to provide greater bandwidth to application and network operations. In addition, the hardware acts as a first-line filter for non-intended packets. The SN260 MAC utilizes a DMA interface to RAM memory to further reduce the overall micro controller interaction when transmitting or receiving packets. When a packet is ready for transmission, the software configures the TX MAC DMA by indicating the packet buffer RAM location. The MAC waits for the backoff period, then transitions the baseband to TX mode and performs channel assessment. When the channel is clear, the MAC reads data from the RAM buffer, calculates the CRC, and provides 4-bit symbols to the baseband. When the final byte has been read and sent to the baseband, the CRC remainder is read and transmitted. The MAC resides in RX mode most of the time, and different format and address filters keep non-intended packets from using excessive RAM buffers, as well as preventing the SN260 CPU from being interrupted. When the reception of a packet begins, the MAC reads 4-bit symbols from the baseband and calculates the CRC. It assembles the received data for storage in a RAM buffer. A RX MAC DMA provides direct access to the RAM memory. Once the packet has been received, additional data is appended to the end of the packet in the RAM buffer space. The appended data provides statistical information on the packet for the software stack.
16/88
SN260 The primary features of the MAC are:
Functional description
CRC generation, appending, and checking Hardware timers and interrupts to achieve the MAC symbol timing Automatic preamble, and SFD pre-pended to a TX packet Address recognition and packet filtering on received packets Automatic acknowledgement transmission Automatic transmission of packets from memory Automatic transmission after backoff time if channel is clear (CCA) Automatic acknowledgement checking Time stamping of received and transmitted messages Attaching packet information to received packets (LQI, RSSI, gain, time stamp, and packet status) IEEE 802.15.4-2003 timing and slotted/unslotted timing
5.4
Packet trace interface (PTI)
The SN260 integrates a true PHY-level PTI for effective network-level debugging. This twosignal interface monitors all the PHY TX and RX packets (in a non-intrusive manner) between the MAC and baseband modules. It is an asynchronous 500kbps interface and cannot be used to inject packets into the PHY/MAC interface. The two signals from the SN260 are the frame signal (PTI_EN) and the data signal (PTI_DATA). The PTI is supported by InSight Desktop.
5.5
16-bit microprocessor
The SN260 integrates the XAP2b microprocessor developed by Cambridge Consultants Ltd., making it a true network processor solution. The XAP2b is a 16-bit Harvard architecture processor with separate program and data address spaces. The word width is 16 bits for both the program and data sides. The standard XAP2 microprocessor and accompanying software tools have been enhanced to create the XAP2b microprocessor used in the SN260. The XAP2b adds data-side byte addressing support to the XAP2 allowing for more productive usage of RAM and optimized code. The XAP2b clock speed is 12MHz. When used with the EmberZNet stack, firmware is loaded into Flash memory over the air or by a serial link using a built-in bootloader in a reserved area of the Flash. Alternatively, firmware may be loaded via the SIF interface with the assistance of RAM-based utility routines also loaded via SIF.
5.6
Embedded memory
The SN260 contains embedded Flash and RAM memory for firmware storage and execution. In addition it partitions a portion of the Flash for simulated EEPROM and token storage.
17/88
Functional description
SN260
5.6.1
Simulated EEPROM
The protocol stack reserves a section of Flash memory to provide simulated EEPROM storage area for stack and customer tokens. The Flash cell has been qualified for a data retention time of >100 years at room temperature and is rated to have a guaranteed 1,000 write/erase cycles. Because the Flash cells are qualified for up to 1,000 write cycles, the simulated EEPROM implements an effective wear-leveling algorithm which effectively extends the number of write cycles for individual tokens. The number of set-token operations is finite due to the write cycle limitation of the Flash. It is not possible to guarantee an exact number of set-token operations because the life of the simulated EEPROM depends on which tokens are written and how often. The SN260 stores non-volatile information necessary for network operation as well as 8 tokens available to the Host (see section Section 7.2.6: Tokens on page 37). The majority of internal tokens are only written when the SN260 performs a network join or leave operation. As a simple estimate of possible set-token operations, consider an SN260 in a stable network (no joins or leaves) not sending any messages where the Host uses only one of the 8-byte tokens available to it. Under this scenario, a very rough estimate results in approximately 330,000 possible set-token operations. The number of possible set-token calls, though, depends on which tokens are being set, so the ratios of set-token calls for each token plays a large factor. A very rough estimate for the total number of times an App token can be set is approximately 320,000. These estimates would typically increase if the SN260 is kept closer to room temperature, since the 1,000 guaranteed write cycles of the Flash is for across temperature.
5.6.2
Flash information area (FIA)
The SN260 also includes a separate 1024-byte FIA that can be used for storage of data during manufacturing, including serial numbers and calibration values. Programming of this special Flash page can only be enabled using the SIF interface to prevent accidental corruption or erasure. The EmberZNet stack reserves a small portion of this space for its own use and in addition makes eight manufacturing tokens available to the application. See Section 7.2.6: Tokens on page 37, for more information.
5.7
Encryption accelerator
The SN260 contains a hardware AES encryption engine that is attached to the CPU using a memory-mapped interface. NIST-based CCM, CCM*, CBC-MAC, and CTR modes are implemented in hardware. These modes are described in the IEEE 802.15.4-2003 specification, with the exception of CCM*, which is described in the ZigBee Security Services Specification 1.0. The EmberZNet stack implements a security API for applications that require security at the application level.
18/88
SN260
Functional description
5.8
Reset detection
The SN260 contains multiple reset sources. The reset event is logged into the reset source register, which lets the CPU determine the cause of the last reset. The following reset causes are detected:
Power-on-reset Watchdog PC rollover Software reset Core power dip
5.9
Power-on-reset (POR)
Each voltage domain (1.8V digital core supply VDD_CORE and pads supply VDD_PADS) has a power-on-reset (POR) cell. The VDD_PADS POR cell holds the always-powered high-voltage domain in reset until the following conditions have been met:
The high-voltage pads supply VDD_PADS voltage rises above a threshold. The internal RC clock starts and generates three clock pulses. The 1.8V POR cell holds the main digital core in reset until the regulator output voltage rises above a threshold.
Additionally, the digital domain counts 1,024 clock edges on the 24MHz crystal before releasing the reset to the main digital core. Table 11 lists the features of the SN260 POR circuitry. Table 11. POR specifications
Parameter VDD_PADS POR release VDD_PADS POR assert 1.8V POR release 1.8V POR hysteresis Min. 1.0 0.5 1.35 0.08 Typ. 1.2 0.6 1.5 0.1 Max. 1.4 0.7 1.65 0.12 Unit V V V V
5.10
Clock sources
The SN260 integrates two oscillators: a high-frequency 24MHz crystal oscillator and a lowfrequency internal 10kHz RC oscillator.
5.10.1
High-frequency crystal oscillator
The integrated high-frequency crystal oscillator requires an external 24MHz crystal with an accuracy of 40ppm. Based upon the application bill of materials and current consumption requirements, the external crystal can cover a range of ESR requirements. For a lower ESR, the cost of the crystal increases but the overall current consumption decreases. Likewise, for higher ESR, the cost decreases but the current consumption increases. Therefore, the designer can choose a crystal to fit the needs of the application.
19/88
Functional description Table 12 lists the specifications for the high-frequency crystal. Table 12. High-frequency crystal specifications
Test conditions Min. Typ. 24 40 60 - 120 Initial, temperature, and aging Load capacitance of 10pF Load capacitance of 18pF - 40 + 40 100 60 1 2 Good crystal: 20 ESR, 10pF load Worst-case crystals (60, 18pF or 100, 10pF) At maximum bias 0.2 0.3 0.5 1 Max.
SN260
Parameter Frequency Duty cycle Phase noise from 1kHz to 100kHz Accuracy Crystal ESR Crystal ESR Star t-up time to stable clock (max. bias) Star t-up time to stable clock (optimum bias) Current consumption Current consumption Current consumption
Unit MHz % dBc/Hz ppm W W ms ms mA mA mA
5.10.2
Internal RC oscillator
The SN260 has a low-power, low-frequency RC oscillator that runs all the time. Its nominal frequency is 10kHz. It is divided down to 1kHz using a variable divider to allow software to accurately calibrate it. This calibrated clock is used by the sleep timer. Time-keeping accuracy depends on temperature fluctuations the chip is exposed to, power supply impedance, and the calibration interval, but in general it will be better than 150ppm (including crystal error of 40ppm). Table 13 lists the specifications of the RC oscillator. Table 13. RC oscillator specifications
Parameter Frequency Analog trim steps Frequency variation with supply For a voltage drop from 3.6V to 3.1V or 2.6V to 2.1V Test conditions Min. Typ. 10 1 0.75 1.5 Max. Unit kHz kHz %
20/88
SN260
Functional description
5.11
Random number generator
The SN260 allows for the generation of random numbers by exposing a randomly generated bit from the RX ADC. Analog noise current is passed through the RX path, sampled by the receive ADC, and stored in a register. The value contained in this register could be used to seed a software-generated random number. The EmberZNet stack utilizes these random numbers to seed the random MAC backoff and encryption key generators.
5.12
Watchdog timer
The SN260 contains an internal watchdog timer clocked from the internal oscillator. If the timer reaches its time-out value of approximately 2 seconds, it will reset the SN260. This reset signal cannot be routed externally to the Host. The SN260 firmware will periodically restart the watchdog timer while the firmware is running normally. The Host cannot effect or configure the watchdog timer.
5.13
Sleep timer
The 16-bit sleep timer is contained in the always-powered digital block. The clock source for the sleep timer is a calibrated 1kHz clock. The frequency is slowed down with a 2N prescaler to generate a final timer resolution of 1ms. With a 1ms tick and a 16-bit timer, the timer wraps about every 65.5 seconds. The EmberZNet stack appropriately handles timer wraps allowing the Host to order a theoretical maximum sleep delay of 4 million seconds.
5.14
Power management
The SN260 supports four different power modes: active, idle, deep sleep, and power down. Active mode is the normal, operating state of the SN260. While in idle mode, code execution halts until any interrupt occurs. All modules of the SN260 including the radio continue to operate normally. The EmberZNet stack automatically invokes idle as appropriate. Deep sleep mode and power down mode both power off most of the SN260, including the radio, and leave only the critical chip functions powered. The internal regulator is disabled and VREG_OUT is turned off. All output signals are maintained in a frozen state. Upon waking from deep sleep or power down mode, the internal regulator is re-enabled. Deep sleep and power down result in the same sleep current consumption. The two sleep modes differ as follows: the SN260 can wake on both an internal timer and an external signal from deep sleep mode; power down mode can only wake on an external signal.
21/88
SPI protocol
SN260
6
SPI protocol
The SN260 low level protocol centers on the SPI interface for communication with a pair of GPIO for handshake signaling.
The SN260 looks like a hardware peripheral. The SN260 is the slave device and all transactions are initiated by the Host (the master). The SN260 supports a reasonably high data rate.
6.1
Physical interface configuration
The SN260 supports both SPI Slave Mode 0 (clock is idle low, sample on rising edge) and SPI Slave Mode 3 (clock is idle high, sample on rising edge) at a maximum SPI clock rate of 5MHz, as illustrated in Figure 3.
Note:
The convention for the waveforms in this document is to show Mode 0. Figure 3. SPI transfer format, Mode 0 and Mode 3
The nHOST_INT signal and the nWAKE signal are both active low. The Host must supply a pull-up resistor on the nHOST_INT signal to prevent errant interruptions during undefined events such as the SN260 resetting. The SN260 supplies an internal pull-up on the nWAKE signal to prevent errant interruptions during undefined events such as the Host resetting.
6.2
SPI transaction
The basic SN260 SPI transaction is half-duplex to ensure proper framing and to give the SN260 adequate response time. The basic transaction, as shown in Figure 4, is composed of three sections: Command, Wait, and Response. The transaction can be considered analogous to a function call. The Command section is the function call, and the Response section is the return value. Figure 4. General timing diagram for a SPI transaction
22/88
SN260
SPI protocol
6.2.1
Command section
The Host begins the transaction by asserting the Slave Select and then sending a command to the SN260. This command can be of any length from 2 to 128 bytes and must not begin with 0xFF. During the Command section, the SN260 will respond with only 0xFF. The Host should ignore data on MISO during the Command section. Once the Host has completed transmission of the entire message, the transaction moves to the Wait section.
6.2.2
Wait section
The Wait section is a period of time during which the SN260 may be processing the command or performing other operations. Note that this section can be any length of time up to 200 milliseconds. Because of the variable size of the Wait section, an interrupt-driven or polling-driven method is suggested for clocking the SPI as opposed to a DMA method. Since the SN260 can require up to 200 milliseconds to respond, as long as the Host keeps Slave Select active, the Host can perform other tasks while waiting for a Response. To determine when a Response is ready, use one of two methods:
Clock the SPI until the SN260 transmits a byte other than 0xFF. Interrupt on the falling edge of nHOST_INT.
The first method, clocking the SPI, is recommended due to simplicity in implementing. During the Wait section, the SN260 will transmit only 0xFF and will ignore all incoming data until the Response is ready. When the SN260 transmits a byte other than 0xFF, the transaction has officially moved into the Response section. Therefore, the Host can poll for a Response by continuing to clock the SPI by transmitting 0xFF and waiting for the SN260 to transmit a byte other than 0xFF. The SN260 will also indicate that a Response is ready by asserting the nHOST_INT signal. The falling edge of nHOST_INT is the indication that a Response is ready. Once the nHOST_INT signal asserts, nHOST_INT will return to idle after the Host begins to clock data.
6.2.3
Response section
When the SN260 transmits a byte other than 0xFF, the transaction has officially moved into the Response section. The data format is the same format used in the Command section. The response can be of any length from 2 to 128 bytes and will not begin with 0xFF. Depending on the actual response, the length of the response is known from the first or second byte and this length should be used by the Host to clock out exactly the correct number of bytes. Once all bytes have been clocked, it is allowable for the Host to de-assert chip select. Since the Host is in control of clocking the SPI, there are no ACKs or similar signals needed back from the Host because the SN260 will assume the Host could accept the bytes being clocked on the SPI. After every transaction, the Host must hold the Slave Select high for a minimum of 1ms. This timing requirement is called the inter-command spacing and is necessary to allow the SN260 to process a command and become ready to accept a new command.
6.2.4
Asynchronous signaling
When the SN260 has data to send to the Host, it will assert the nHOST_INT signal. The nHOST_INT signal is designed to be an edge-triggered signal as opposed to a leveltriggered signal; therefore, the falling edge of nHOST_INT is the true indicator of data availability. The Host then has the responsibility to initiate a transaction to ask the SN260 for its output. The Host should initiate this transaction as soon as possible to prevent possible
23/88
SPI protocol
SN260
backup of data in the SN260. The SN260 will de-assert the nHOST_INT signal after receiving a byte on the SPI. Due to inherent latency in the SN260, the timing of when the nHOST_INT signal returns to idle can vary between transactions. nHOST_INT will always return to idle for a minimum of 10s before asserting again. If the SN260 has more output available after the transaction has completed, the nHOST_INT signal will assert again after Slave Select is de-asserted and the Host must make another request.
6.2.5
Spacing
To ensure that the SN260 is always able to deal with incoming commands, a minimum intercommand spacing is defined at 1ms. After every transaction, the Host must hold the Slave Select high for a minimum of 1ms. The Host must respect the inter-command spacing requirement, or the SN260 will not have time to operate on the command; additional commands could result in error conditions or undesired behavior. If the nHOST_INT signal is not already asserted, the Host is allowed to use the Wake handshake instead of the intercommand spacing to determine if the SN260 is ready to accept a command.
6.2.6
Waking the SN260 from sleep
Waking up the SN260 involves a simple handshaking routine as illustrated in Figure 5. This handshaking ensures that the Host will wait until the SN260 is fully awake and ready to accept commands from the Host. If the SN260 is already awake when the handshake is performed (such as when the Host resets and the SN260 is already operating), the handshake will proceed as described below with no ill effects.
Note:
A wake handshake cannot be performed if nHOST_INT is already asserted. Figure 5. SN260 wake sequence
Waking the SN260 involves the following steps: 1. 2. 3. 4. Host asserts nWAKE. SN260 interrupts on nWAKE and exits sleep. SN260 performs all operations it needs to and will not respond until it is ready to accept commands. SN260 asserts nHOST_INT within 10ms of nWAKE asserting. If the SN260 does not assert nHOST_INT within 10ms of nWAKE, it is valid for the Host to consider the SN260 unresponsive and to reset the SN260. Host detects nHOST_INT assertion. Since the assertion of nHOST_INT indicates the SN260 can accept SPI transactions, the Host does not need to hold Slave Select high for the normally required minimum 1ms of inter-command spacing. Host de-asserts nWAKE after detecting nHOST_INT assertion. SN260 will de-assert nHOST_INT within 25s of nWAKE de-asserting. After 25s, any change on nHOST_INT will be an indication of a normal asynchronous (callback) event.
5.
6. 7. 8.
24/88
SN260
SPI protocol
6.2.7
Error conditions
If two or more different error conditions occur back to back, only the first error condition will be reported to the Host (if it is possible to report the error). The following are error conditions that might occur with the SN260.
Oversized EZSP frame If the transaction includes an EZSP Frame, the Length Byte cannot be a value greater than 125. If the SN260 detects a length byte greater than 125, it will drop the incoming Command and abort the entire transaction. The SN260 will then assert nHOST_INT after Slave Select returns to Idle to inform the Host through an error code in the Response section what has happened. Not only is the Command in the problematic transaction dropped by the SN260, but the next Command is also dropped, because it is responded to with the Oversized EZSP Frame Error Response.
Aborted transaction An aborted transaction is any transaction where Slave Select returns to Idle prematurely and the SPI Protocol dropped the transaction. The most common reason for Slave Select returning to Idle prematurely is the Host unexpectedly resetting. If a transaction is aborted, the SN260 will assert nHOST_INT to inform the Host through an error code in the Response section what has happened. When a transaction is aborted, not only does the Command in the problematic transaction get dropped by the SN260, but the next Command also gets dropped since it is responded to with the Aborted Transaction Error Response.
Missing frame terminator Every Command and Response must be terminated with the Frame Terminator byte. The SN260 will drop any Command that is missing the Frame Terminator. The SN260 will then immediately provide the Missing Frame Terminator Error Response.
Long transaction A Long Transaction error occurs when the Host clocks too many bytes. As long as the inter-command spacing requirement is met, this error condition should not cause a problem, since the SN260 will send only 0xFF outside of the Response section as well as ignore incoming bytes outside of the Command section.
Unresponsive Unresponsive can mean the SN260 is not powered, not fully booted yet, incorrectly connected to the Host, or busy performing other tasks. The Host must wait the maximum length of the Wait section before it can consider the SN260 unresponsive to the Command section. This maximum length is 200 milliseconds, measured from the end of the last byte sent in the Command Section. If the SN260 ever fails to respond during the Wait section, it is valid for the Host to consider the SN260 unresponsive and to reset the SN260. Additionally, if nHOST_INT does not assert within 10ms of nWAKE asserting during the wake handshake, the Host can consider the SN260 unresponsive and reset the SN260.
6.3
SPI protocol timing
Figure 6 illustrates all critical timing parameters in the SPI Protocol. These timing parameters are a result of the SN260's internal operation and both constrain Host behavior and characterize SN260 operation. The parameters shown are discussed elsewhere in this document. Note that Figure 6 is not drawn to scale, but is provided to illustrate where the parameters are measured.
25/88
SPI protocol Figure 6. SPI protocol timing waveform
SN260
Table 14 lists the timing parameters of the SPI protocol. These parameters are illustrated in Figure 6. Table 14.
Parameter t1 (a) t1 (b) t2 t3 t4 t5 t6 t7 t8 t9 t10
SPI protocol timing parameters
Description Wake handshake, while 260 is awake Wake handshake, while 260 is asleep Wake handshake finish Reset pulse width Star tup time nHOST_INT de-asserting after Command Clock rate Wait section nHOST_INT de-asserting after Response nHOST_INT asserting after transaction Inter-command spacing 13 200 25 20 25 1 755 130 70 20 0 0 800 800 1.1 8 250 35 1500 75 Min. Typ. 133 7.3 1.2 Max. 150 10 25 Unit s ms s s ms s ns s s s ms
6.4
Data format
The data format, also referred to as a command, is the same for both the Command section and the Response section. The data format of the SPI Protocol is straightforward, as illustrated in Figure 7.
Figure 7.
SPI protocol data format
The total length of a command must not exceed 128 bytes. All commands must begin with the SPI Byte. Some commands are only two bytes--that is, they contain the SPI Byte and Frame Terminator only.
26/88
SN260
SPI protocol The Length Byte is only included if there is information in the EZSP Frame (EmberZNet Serial Protocol Frame) and the Length Byte defines the length of just the EZSP Frame. Therefore, if a command includes an EZSP Frame, the Length Byte can have a value from 2 through 125 and the overall command size will be 5 through 128 bytes. The SPI Byte can be a specific value indicating if there is an EZSP Frame or not, and if there is an EZSP Frame, then the Length Byte can be expected. The Error Byte is used by the error responses to provide additional information about the error and appears in place of the length byte. This additional information is described in the following sections. The EZSP Frame contains the data needed for operating EmberZNet. The EZSP Frame and its format are explained in Section 7: EmberZNet serial protocol on page 34. The Frame Terminator is a special control byte used to mark the end of a command. The Frame Terminator byte is defined as 0xA7 and is appended to all Commands and Responses immediately after the final data byte. The purpose of the Frame Terminator is to provide a known byte the SPI Protocol can use to detect a corrupt command. For example, if the SN260 resets during the Response Section, the Host will still clock out the correct number of bytes. But when the host attempts to verify the value 0xA7 at the end of the Response, it will see either the value 0x00 or 0xFF and know that the SN260 just reset and the corrupt Response should be discarded.
Note:
The Length Byte only specifies the length of the EZSP Frame. It does not include the Frame Terminator.
6.5
Table 15.
Command value Any Any Any
SPI byte
Table 15 lists the possible commands and their responses in the SPI Byte. SPI commands & responses
Command Any Any Any Response value 0x00 0x01 0x02 Response SN260 reset occurred--This is never used in another response; it always indicates an SN260 Reset. Oversized EZSP Frame received--This is never used in another response; it always indicates an overflow occurred. Abor ted Transaction occurred--This is never used in another response; it always indicates an aborted transaction occurred. Missing Frame Terminator--This is never used in another response; it always indicates a missing frame terminator in the command. Reserved [none] bit[7] is always set. bit[6] is always cleared. bit[5:0] is a number from 163. [none] EZSP frame Invalid
Any Any 0x00 0x0F 0x0A 0x0B 0xF0 0xFD 0xFE 0xFF
Any Any Reserved SPI Protocol Version SPI Status Reserved EZSP Frame Invalid
0x03 0x04 [none] 0x81 0xBF
0xC0 0xC1 bit[7] is always set. bit[6] is always set. bit[0]--Set if Alive. [none] 0xFE 0xFF
27/88
SPI protocol
SN260
6.5.1
Primary SPI bytes
There are three primary SPI bytes: SPI protocol version, SPI status, and EZSP frame.
SPI protocol version [0x0A] Sending this command requests the SPI Protocol Version number from the SPI Interface. The response will always have bit 7 set and bit 6 cleared. In this current version, the response will be 0x81, because the version number corresponding to this set of Command-Response values is version number 1. The version number can be a value from 1 to 63 (0x810xBF).
SPI status [0x0B] Sending this command asks for the SN260 status. The response status byte will always have the upper 2 bits set. In this current version, the status byte only has one status bit [0], which is set if the SN260 is alive and ready for commands.
EZSP frame [0xFE] This byte indicates that the current transaction is an EZSP transaction and there is more data to follow. This SPI Byte, and only this SPI Byte, will cause the transaction to look like the full data format illustrated in Figure 7. The byte immediately after this SPI Byte will be a Length Byte, and it is used to identify the length of the EZSP Frame. The EZSP Frame is defined in section Section 7: EmberZNet serial protocol on page 34. If the SPI Byte is 0xFE, it means the minimum transaction size is five bytes. All other SPI Bytes mean the transaction size is two or three bytes.
6.5.2
Special response bytes
There are only five SPI Byte values, 0x000x04, ever used as error codes (see Table 16). When the error condition occurs, any command sent to the SN260 will be ignored and responded to with one of these codes. These special SPI Bytes must be trapped and dealt with. In addition, for each error condition the Error Byte (instead of the Length Byte) is also sent with the SPI Byte.
Table 16.
SPI byte value 0x00
Byte values used as error codes
Error message Error description See Section 6.6: Powering on, power cycling, and rebooting. The command contained an EZSP frame with a Length Byte greater than 125. The SN260 was forced to drop the entire command. The transaction was not completed properly and the SN260 was forced to abort the transaction. Error byte description The reset type. Refer to the API documentation discussing EmberResetType. Reser ved
SN260 Reset
0x01
Oversized EZSP Frame Abor ted Transaction Missing Frame Terminator Reserved
0x02
Reser ved
0x03 0x04
The command was missing the Frame Terminator. The SN260 was forced to drop the Reser ved entire command. [none] [none]
28/88
SN260
SPI protocol
6.6
Powering on, power cycling, and rebooting
When the Host powers on (or reboots), it cannot guarantee that the SN260 is awake and ready to receive commands. Therefore, the Host should always perform the Wake SN260 handshake to guarantee that the SN260 is awake. If the SN260 resets, it needs to inform the Host so that the Host can reconfigure the stack if needed. When the SN260 resets, it will assert the nHOST_INT signal, telling the Host that it has data. The Host should request data from the SN260 as usual. The SN260 will ignore whatever command is sent to it and respond only with two bytes. The first byte will always be 0x00 and the second byte will be the reset type as defined by EmberResetType. This specialty SPI Byte is never used in another Response SPI Byte. If the Host sees 0x00 from the SN260, it knows that the SN260 has been reset. The SN260 will de-assert the nHOST_INT signal shortly after receiving a byte on the SPI and process all further commands in the usual manner. In addition to the Host having control of the reset line of the SN260, the EmberZNet Serial Protocol also provides a mechanism for a software reboot.
6.6.1
Unexpected resets
The SN260 is designed to protect itself against undefined behavior due to unexpected resets. The protection is based on the state of Slave Select since the inter-command spacing mandates that Slave Select must return to idle. The SN260's internal SPI Protocol uses Slave Select returning to idle as a trigger to re-initialize its SPI Protocol. By always reinitializing, the SN260 is protected against the Host unexpectedly resetting or terminating a transaction. Additionally, if Slave Select is active when the SN260 powers on, the SN260 will ignore SPI data until Slave Select returns to idle. By ignoring SPI traffic until idle, the SN260 will not begin receiving in the middle of a transaction. If the Host resets, in most cases it should reset the SN260 as well so that both devices are once again in the same state: freshly booted. Alternately, the Host can attempt to recover from the reset by recovering its previous state and resynchronizing with the state of the SN260. If the SN260 resets during a transaction, the Host can expect either a Wait Section timeout or a missing Frame Terminator indicating an invalid Response. If the SN260 resets outside of a transaction, the Host should proceed normally.
6.7
Transaction examples
This section contains the following transaction examples:
SPI protocol version EmberZNet serial protocol frame -- NOP command SN260 reset Three-par t transaction: Wake, Get Version, Stack Status Callback
29/88
SPI protocol
SN260
6.7.1
SPI protocol version
Figure 8. SPI protocol version example
1. 2. 3. 4. 5. 6. 7. 8.
Activate Slave Select (nSSEL). Transmit the command 0x0A - SPI Protocol Version Request. Transmit the Frame Terminator, 0xA7. Wait for nHOST_INT to assert. Transmit and receive 0xFF until a byte other than 0xFF is received. Receive response 0x81 (a byte other than 0xFF), then receive the Frame Terminator, 0xA7. Bit 7 is always set and bit 6 is always cleared in the Version Response, so this is Version 1. De-activate Slave Select.
6.7.2
EmberZNet serial protocol frame -- NOP command
Figure 9. EmberZNet serial protocol frame - NOP command example
1. 2.
Activate Slave Select (nSSEL). Transmit the appropriate command: 0xFE: SPI Byte indicating an EZSP Frame 0x02: Length Byte showing the EZSP Frame is 2 bytes long 0x00: EZSP Frame Control Byte indicating a command with no sleeping 0x05: EZSP Frame Type Byte indicating the NOP command 0xA7: Frame Terminator
3. 4. 5.
Wait for nHOST_INT to assert. Transmit and receive 0xFF until a byte other than 0xFF is received. Receive response 0xFE (a byte other than 0xFF) and read the next byte for a length.
30/88
SN260 6. 7.
SPI protocol Stop transmitting after the number of bytes (length) is received plus the Frame Terminator. Decode the response: 8. 0xFE: SPI Byte indicating an EZSP Frame 0x02: Length Byte showing the EZSP Frame is 2 bytes long 0x80: EZSP Frame Control Byte indicating a response with no overflow 0x05: EZSP Frame Type Byte indicating the NOP response 0xA7: Frame Terminator
De-activate Slave Select.
6.7.3
SN260 reset
Figure 10. SN260 reset example
1. 2. 3.
nHOST_INT asserts. Activate Slave Select (nSSEL). Transmit the command: 0xFE: SPI Byte indicating an EZSP Frame 0x02: Length Byte showing the EZSP Frame is 2 bytes long 0x00: EZSP Frame Control Byte indicating a command with no sleeping 0x06: EZSP Frame Type Byte indicating the callback command 0xA7: Frame Terminator
4. 5. 6. 7. 8. 9.
Wait for nHOST_INT to assert. Transmit and receive 0xFF until a byte other than 0xFF is received. Receive response 0x00 (a byte other than 0xFF). Receive the Error Byte and decode (0x02 is enumerated as RESET_POWERON). Receive the Frame Terminator (0xA7). Response 0x00 indicates the SN260 has reset and the Host should respond appropriately.
10. Deactivate Slave Select. 11. Since nHOST_INT does not assert again, there is no more data for the Host.
31/88
SPI protocol
SN260
6.7.4
Three-part transaction: Wake, Get Version, Stack Status Callback
Figure 11. Timing diagram of the three-part transaction
1. 2. 3. 4. 5. 6. 7. 8. 9.
Activate nWAKE and activate timeout timer. SN260 wakes up (if not already) awake and enables communication. nHOST_INT asserts, indicating the SN260 can accept commands. Host sees nHOST_INT activation within 10ms and deactivates nWAKE and timeout timer. nHOST_INT de-asserts immediately after nWAKE. Activate Slave Select. Transmit the Command 0x0A - SPI Protocol Version Request. Transmit the Frame Terminator, 0xA7. Wait for nHOST_INT to assert.
10. Transmit and receive 0xFF until a byte other than 0xFF is received. 11. Receive response 0x81 (a byte other than 0xFF), then receive the Frame Terminator, 0xA7. 12. Bit 7 is always set and bit 6 is always cleared in the Version Response, so this is Version 1. 13. Deactivate Slave Select. 14. Host begins timing the inter-command spacing of 1ms in preparation for sending the next command. 15. nHOST_INT asserts shortly after deactivating Slave Select, indicating a callback. 16. Host sees nHOST_INT, but waits for the 1ms before responding. 17. Activate Slave Select. 18. Transmit the command: 0xFE: SPI Byte indicating an EZSP Frame 0x02: Length Byte showing the EZSP Frame is 2 bytes long 0x00: EZSP Frame Control Byte indicating a command with no sleeping 0x06: EZSP Frame Type Byte indicating the callback command 0xA7: Frame Terminator
19. Wait for nHOST_INT to assert. 20. Transmit and receive 0xFF until a byte other than 0xFF is received. 21. Receive response 0xFE (a byte other than 0xFF), read the next byte for a length. 22. Stop transmitting after the number of bytes (length) is received plus the Frame Terminator.
32/88
SN260 23. Decode the response: 0xFE: SPI Byte indicating an EZSP Frame 0x03: Length Byte showing the EZSP Frame is 3 bytes long
SPI protocol
0x80: EZSP Frame Control Byte indicating a response with no overflow 0x19: EZSP Frame Type Byte indicating the emberStackStatusHandler command 0x91: EmberStatus EMBER_NETWORK_DOWN from emberStackStatusHandler 0xA7 Frame Terminator
24. Deactivate Slave Select. 25. Since nHOST_INT does not assert again, there is no more data for the Host.
33/88
EmberZNet serial protocol
SN260
7
EmberZNet serial protocol
EmberZnet Serial Protocol (EZSP) is designed to be very familiar to customers who have used the EmberZNet 2.x stack API. The majority of the commands and responses are functionally identical to those found in EmberZNet 2.x. The variations are due mainly to the timing differences of running the application on a separate processor across a serial interface. Communication between the SN260 and the Host consists of a two-message transaction. The Host sends a command message to the SN260 and then the SN260 sends a response message to the Host. If the SN260 needs to communicate asynchronously with the Host, it will indicate this by using the interrupt line and then waiting for the Host to send the callback command. All EZSP frames begin with a Frame Control Byte followed by a Frame ID Byte. The format of the rest of the frame depends on the frame ID. Section 7.3: Protocol format on page 38 defines the format for all the frame IDs. Most of the frames have a fixed length. A few, such as those containing application messages, are of variable length. The frame control indicates the direction of the message (command or response). For commands, the frame control also contains power management information, and for responses it also contains status information. When a command contains an application message, the Host must supply a one-byte tag. This tag is used in future commands and responses to refer to the message. For example, when sending a message, the Host provides both the message contents and a tag. The tag is then used to report the fate of the message in a later response from the SN260.
7.1
Byte order
All multiple octet fields are transmitted and received with the least significant octet first, also referred to as little endian. This is the same byte order convention specified by 802.15.4 and ZigBee. Note that EUI64 fields are treated as a 64-bit number and are therefore transmitted and received in little endian order. Each individual octet is transmitted with the most significant bit first, as shown in Section 6.1: Physical interface configuration on page 22.
7.2
Conceptual overview
This section provides an overview of the concepts that are specific to the SN260 or that differ from the EmberZNet 2.x stack API. The commands and responses mentioned in this overview are described in more detail later in this document.
7.2.1
Stack configuration
The Host can use the version command to obtain information about the firmware running on the SN260. There are a number of configuration values that affect the behavior of the stack. The Host can read these values at any time using the getConfigurationValue command. After the SN260 has reset, the Host can modify any of the default values using the setConfigurationValue command. The Host must then provide information about the application endpoints using the addEndpoint command. Table 17 gives the minimum, default and maximum values for each of the configuration values. Also listed is the RAM cost. This is the number of bytes of additional RAM required to increase the configuration value by one. Since the total amount of RAM is fixed, the
34/88
SN260
EmberZNet serial protocol additional RAM required must be made available by reducing one of the other configuration values.
Table 17.
Configuration values
Value Min. Def. Max. Units packet buffers 16 neighbors RAM Cost 40 Description The number of packet buffers available to the stack. The maximum number of router neighbors the stack can keep track of. A neighbor is a node within radio range. The maximum number of datagram and sequenced messages the stack can have in the process of being either transmitted or received at any given time. The maximum number of bindings supported by the stack. It includes the bindings in EEPROM and in RAM. The number of binding table entries in RAM. The number of binding table entries that can concurrently support an open sequenced connection. The maximum number of destinations to which a node can route messages. This include both messages originating at this node and those relayed for others. The number of simultaneous route discoveries that a node will support. End-device child endpoints larger than this value will not have their discovery information cached by their router parent. The size of an entry in the end device discovery cache on a router. Endpoint descriptions longer than this will not be cached. The number of entries in the discovery cache on a router. Each end device child requires 1 + (D) entries. The cache is held in EEPROM. Specifies the stack profile. The security level used for security at the MAC and network layers. The supported values are 0 (no security) and 5 (payload is encrypted and a four-byte MIC is used for authentication). The maximum number of hops for a message. The maximum number of end device children that a router will support. The maximum amount of time that the MAC will hold a message for indirect transmission to a child.
EZSP_CONFIG_PACKET_BUFFER_ COUNT EZSP_CONFIG_NEIGHBOR_TABLE_ SIZE
5
24
8
16
18
EZSP_CONFIG_TRANSPORT_ PACKET_COUNT
0
10
m essages
10
EZSP_CONFIG_BINDING_ TABLE_SIZE (A) EZSP_CONFIG_TEMPORARY_ BINDING_ENTRIES (B) EZSP_CONFIG_TRANSPORT_ CONNECTION_COUNT
0
8
32 + (B) (A)
en tr ies
3
0
8
e n tr i e s
12
0
0
e n tr i e s
12
EZSP_CONFIG_ROUTE_ TABLE_SIZE (C) EZSP_CONFIG_DISCOVERY_ TABLE_SIZE EZSP_CONFIG_DISCOVERY_ CACHE_ENDPOINTS (D)
0
16
e n tr i e s
6
0
8
e n tr i e s
10
0
4
endpoints
0
EZSP_CONFIG_DISCOVERY_ CACHE_ENTRY_SIZE
11 + (D)
15
15
bytes
0
EZSP_CONFIG_DISCOVERY_ CACHE_SIZE EZSP_CONFIG_STACK_PROFILE
0 0
35 0
35
e n tr i e s
0 0
EZSP_CONFIG_SECURITY_LEVEL
0
5
5
0
EZSP_CONFIG_MAX_HOPS EZSP_CONFIG_MAX_END_DEVICE_ CHILDREN (E) EZSP_CONFIG_INDIRECT_ TRANSMISSION_TIMEOUT
0 0
10 6 32
hops childre n milliseconds
0 4
0
3000 30000
0
35/88
EmberZNet serial protocol
Table 17. Configuration values (continued)
Value Min. Def. Max. Units RAM Cost Description
SN260
EZSP_CONFIG_RESERVED_ ROUTING_ENTRIES
0
0
(C)
e n tr i e s
0
The number of route table entries that are reserved for temporary aggregation routes in the mesh stack. The maximum amount of time that a mobile node can wait between polls. If no poll is heard within this timeout, then the parent removes the mobile node from its tables. The number of child table entries reserved for use only by mobile nodes. The amount of RAM available for use by the Host. Enables boost power mode and/or the alternate transmitter output.
EZSP_CONFIG_MOBILE_NODE_ POLL_TIMEOUT EZSP_CONFIG_RESERVED_ MOBILE_CHILD_ENTRIES EZSP_CONFIG_HOST_RAM EZSP_CONFIG_TX_POWER_MODE
0
20
quar ter seconds
0
0 0 0
0 0 0
(E) 255 3
e n tr i e s bytes
0 1 0
7.2.2
Policy settings
There are some situations when the SN260 must make a decision but there isn't enough time to consult with the Host. The Host can control what decision is made by setting the policy in advance. The SN260 will then make decisions according to the current policy. The Host is informed via callbacks each time a decision is made, but by the time the news reaches the Host, it is too late to change that decision. You can change the policies at any time by using the setPolicy command. A policy is used for trust center behavior, external binding modification requests, datagram replies, generating pollHandler callbacks, and the contents of the unicastSent and messageSent callbacks.
7.2.3
Datagram replies
The policy for datagram replies allows the Host to decide whether it wants to supply the SN260 with a reply payload for every datagram received. If the Host sets the policy to not supply a reply, the SN260 will automatically send an empty reply (containing no payload) for every datagram received. If the Host sets the policy to supply the reply, then the SN260 will only send a reply when instructed by the Host. If the reply does not reach the sender before the transport retry timeout expires, the sender will transmit the datagram again. The Host must process the incoming message and supply the reply quickly enough to avoid retransmission by the sender. Provided this timing constraint is met, multiple datagrams can be received before the first reply is supplied and the replies can be supplied in any order.
7.2.4
Callbacks
Asynchronous callbacks from the SN260 are sent to the Host as the response to a callback command. The SN260 uses the interrupt line to indicate that the Host should send a callback command. The SN260 will queue multiple callbacks while it waits for the Host, and each response only delivers one callback. If the SN260 receives the callback command when there are no pending callbacks, it will reply with the noCallbacks response.
36/88
SN260
EmberZNet serial protocol
7.2.5
Power management
The SN260 will always idle its processor whenever possible. To further reduce power consumption, the SN260 can be put to sleep by the Host. In power down mode, only an external interrupt will wake the SN260. In deep sleep mode, the SN260 will use its internal timer to wake up for scheduled events. The SN260 provides two independent timers that the Host can use for any purpose, including waking up the SN260 from deep sleep mode. Timers are set using the setTimer command and generate timerHandler callbacks. The initial frame control byte of every command tells the SN260 which sleep mode to enter after it has responded to the command. Including this information in every command (instead of having a separate power management command) allows the SN260 to be put to sleep faster. If the Host needs to put the SN260 to sleep without also performing another action, the nop command can be used. In deep sleep mode, the SN260 will wake up for an internal event. If the event does not produce a callback for the Host, the SN260 will go back to sleep once the event has been handled. If the event does produce a callback, the SN260 will signal the Host and remain awake waiting for the callback command. If the frame control byte of the callback command specifies deep sleep mode, then the SN260 would normally go back to sleep after responding with the callback. However, if there is a second callback pending, the SN260 will remain awake waiting for another callback command. To avoid disrupting the operation of the network, only put the SN260 to sleep when it is not joined to a network or when it is joined as a sleeping end device. If the SN260 is joined as a sleeping end device, then it must poll its parent in order to receive messages. The Host controls the polling behavior using the pollForData command. Polls are sent periodically with the interval set by the Host or a single poll can be sent. The result of every poll attempt is optionally reported using the pollCompleteHandler callback.
7.2.6
Tokens
Some of the non-volatile storage on the SN260 is made available for use by the Host. Up to 8 manufacturing tokens stored in the flash information area can be read using the getMfgToken command and up to 8 tokens stored in the simulated EEPROM can be read and written using the setToken and getToken commands. Each token is 8 bytes. Tokens preserve their values between reboots. Refer to section Simulated EEPROM for a description of the simulated EEPROM and write cycle estimates.
7.2.7
RAM
Some of the RAM on the SN260 can be reserved by the Host for its own use. The amount of space reserved is the EZSP_CONFIG_HOST_RAM configuration value (set using the setConfigurationValue command). The Host can then read and write data using the setRam and getRam commands. If the Host chooses to reserve RAM, this will reduce the number of messages and callbacks that the SN260 can buffer.
37/88
EmberZNet serial protocol
SN260
7.2.8
SN260 status
The frame control byte of every response sent by the SN260 contains two status bits:
The overflow bit is set if the SN260 ran out of memory at any time since the previous response was sent. If this bit is set, then messages may have been lost. The truncated bit is set if the SN260 truncated the current response. If this bit is set, the command from the Host produced a response larger than the maximum EZSP frame length.
You can use the nop command to check the status of the SN260 without also performing another action.
7.2.9
Random number generator
The Host can obtain a random number from the SN260 using the getRandomNumber command. The random number is generated from analog noise in the radio and can be used to seed a random number generator on the Host.
7.3
Protocol format
All EZSP frames begin with a frame control byte. Table 18 describes the meaning of this byte for command and response frames. Table 19 describes the sleep modes, Table 20 describes the overflow status bit and Table 21 describes the truncated status bit. The second byte of all EZSP frames is the frame ID byte. Table 18.
Bit 7 (MSB) 6 5 4 3 2 1 0 (LSB)
Frame control byte
Command 0 0 (reserved) 0 (reserved) 0 (reserved) 0 (reserved) 0 (reserved) sleepMode[1] sleepMode[0] Sleep modes sleepMode[0] 1 0 1 0 Description Reserved. Power down. Deep sleep. Idle. Response 1 0 (reserved) 0 (reserved) 0 (reserved) 0 (reserved) 0 (reserved) truncated overflow
Table 19.
sleepMode[1] 1 1 0 0
38/88
SN260 Table 20. Overflow status
Description
EmberZNet serial protocol
overflow 1 0
The SN260 ran out of memory since the previous response. No memory shortage since the previous response.
Table 21.
Truncated status
Description The SN260 truncated the current response to avoid exceeding the maximum EZSP frame length. The current response was not truncated.
truncated 1 0
Section 7.3.1: Type definitions defines all the types used by the SN260 and Section 7.3.2: Structure definitions defines all the structures. Section 7.3.3: Named values enumerates all the named values for the different types. The subsequent sections list all the frames supported by the SN260, specifying the Frame ID, the command parameters and the response parameters. The list is divided into five sections:
Section 7.3.4 lists Configuration frames. Section 7.3.5 lists Utilities frames. Section 7.3.6 lists Networking frames. Section 7.3.7 lists Binding frames. Section 7.3.8 lists Messaging frames.
Finally, section Section 7.3.9 provides an alphabetical list of all the frames.
39/88
EmberZNet serial protocol
SN260
7.3.1
Table 22.
Type definitions
Type definitions
Type Alias int8u int8u int16u int8u int8u int8u int8u int8u int8u int8u int8u int8u int8u int8u int8u int16u int16u int8u[8] True or false. Identifies a configuration value. Values for EZSP_CONFIG_TX_POWER_MODE. Return type for configuration commands. Identifies a policy. Identifies a policy decision. Return type for stack functions. Either marks an event as inactive or specifies the units for the event execution time. The type of the node. The possible join states for a node. Incoming message types. Binding types. Options to use when sending a unicast message. Network scan types. Decision made by the trust center when a node attempts to join. 16-bit ZigBee network address. 802.15.4 PAN ID. EUI 64-bit ID (an IEEE address). Description
boolean EzspConfigId EzspConfigTxPowerMode EzspConfigStatus EzspPolicyId EzspDecisionId EmberStatus EmberEventUnits EmberNodeType EmberNetworkStatus EmberIncomingMessageType EmberBindingType EmberUnicastOption EmberNetworkScanType EmberJoinDecision EmberNodeId EmberPanId EmberEUI64
40/88
SN260
EmberZNet serial protocol
7.3.2
Table 23.
Structure definitions
Structure definitions
Structure Field Description Network parameters.
EmberNetworkParameters
int16u panId int8s radioTxPower int8u radioChannel
The network's PAN identifier. A power setting, in dBm. A radio channel. ZigBee APS frame parameters.
int16u profileId EmberApsFrame int8u clusterId int8u sourceEndpoint
The application profile ID that describes the format of the message. The cluster ID for this message. The source endpoint.
int8u destinationEndpoint The destination endpoint. EmberUnicastOption options A bitmask of options. An entry in the binding table. EmberBindingType type int8u local int8u remote The type of binding. The endpoint on the local node. The endpoint on the remote node (specified by identifier). A cluster ID that matches one from the local endpoint's simple descriptor. This cluster ID is set by the provisioning application to indicate which part an endpoint's functionality is bound to this particular remote node and is used to distinguish between unicast and multicast bindings. A binding can be used to send messages with any cluster ID, not just the one listed in the binding. A 64-bit identifier. This is either the destination EUI64 (for unicasts) or the 64-bit group address (for multicasts).
EmberBindingTableEntry int8u clusterId
EmberEUI64 identifier
41/88
EmberZNet serial protocol
SN260
7.3.3
Table 24.
Named values
boolean
Structure F ield 0x00 0x01 Description An alias for zero, used for clarity. An alias for one, used for clarity.
FALSE TRUE
Table 25.
EzspConfigId
Structure F ield 0x01 0x02 Description The number of packet buffers available to the stack. The maximum number of router neighbors the stack can keep track of. A neighbor is a node within radio range. The maximum number of datagram and sequenced messages the stack can have 'in-flight' at any time. Here, 'in-flight' means 'in the process of being either transmitted or received'. The maximum number of bindings supported by the stack. It includes the bindings in EEPROM and in RAM. The number of binding table entries in RAM. The number of binding table entries that can concurrently support an open sequenced connection. The maximum number of destinations to which a node can route messages. This include both messages originating at this node and those relayed for others. The number of simultaneous route discoveries that a node will support. End-device child endpoints larger than this value will not have their discovery information cached by their router parent. The size of an entry in the end device discovery cache on a router. Endpoint descriptions longer than this will not be cached. The number of entries in the discovery cache on a router. Each end device child requires 1 + EZSP_CONFIG_DISCOVERY_CACHE_ENDPOINTS entries. The cache is held in EEPROM. Specifies the stack profile. The security level used for security at the MAC and network layers. The supported values are 0 (no security) and 5 (payload is encrypted and a four-byte MIC is used for authentication). The maximum number of hops for a message. The maximum number of end device children that a router will support.
EZSP_CONFIG_PACKET_BUFFER_COUNT EZSP_CONFIG_NEIGHBOR_TABLE_SIZE
EZSP_CONFIG_TRANSPORT_PACKET_COUN T
0x03
EZSP_CONFIG_BINDING_TABLE_SIZE EZSP_CONFIG_TEMPORARY_BINDING_ENT RIES EZSP_CONFIG_TRANSPORT_CONNECTION_ COUNT EZSP_CONFIG_ROUTE_TABLE_SIZE
0x04 0x05 0x06
0x07
EZSP_CONFIG_DISCOVERY_TABLE_SIZE EZSP_CONFIG_DISCOVERY_CACHE_ENDPO INTS EZSP_CONFIG_DISCOVERY_CACHE_ENTRY _SIZE
0x08
0x09
0x0A
EZSP_CONFIG_DISCOVERY_CACHE_SIZE
0x0B
EZSP_CONFIG_STACK_PROFILE
0x0C
EZSP_CONFIG_SECURITY_LEVEL
0x0D
EZSP_CONFIG_MAX_HOPS EZSP_CONFIG_MAX_END_DEVICE_CHILDR EN
0x10 0x11
42/88
SN260 Table 25. EzspConfigId (continued)
Structure EZSP_CONFIG_INDIRECT_TRANSMISSION TIMEOUT EZSP_CONFIG_RESERVED_ROUTING_ ENTRIES EZSP_CONFIG_MOBILE_NODE_POLL_ TIMEOUT EZSP_CONFIG_RESERVED_MOBILE_CHILD ENTRIES EZSP_CONFIG_HOST_RAM EZSP_CONFIG_TX_POWER_MODE F ield 0x12 0x13
EmberZNet serial protocol
Description The maximum amount of time that the MAC will hold a message for indirect transmission to a child. The number of route table entries that are reserved for temporary aggregation routes in the mesh stack. The maximum amount of time that a mobile node can wait between polls. If no poll is heard within this timeout, then the parent removes the mobile node from its tables. The number of child table entries reserved for use only by mobile nodes. The amount of RAM available for use by the Host. Enables boost power mode and/or the alternate transmitter output.
0x14
0x15 0x16 0x17
Table 26.
EzspConfigTxPowerMode
Structure F ield 0x00 Description Normal power mode and bi-directional RF transmitter output. Enable boost power mode. This is a high performance radio mode which offers increased receive sensitivity and transmit power at the cost of an increase in power consumption. Enable the alternate transmitter output. This allows for simplified connection to an external power amplifier via the RF_TX_ALT_P and RF_TX_ALT_N pins. Enable both boost mode and the alternate transmitter output.
EMBER_TX_POWER_MODE_DEFAULT
EMBER_TX_POWER_MODE_BOOST
0x01
EMBER_TX_POWER_MODE_ALTERNATE EMBER_TX_POWER_MODE_BOOST_AND_ ALTERNATE
0x02
0x03
Table 27.
EzspConfigStatus
Structure F ield 0x00 0x01 0x02 0x03 0x04 Description The command was successful. Insufficient memory was available. The value was out of bounds. The configuration tag was not recognized. Configuration values can no longer be modified.
EZSP_CONFIG_SUCCESS EZSP_CONFIG_OUT_OF_MEMORY EZSP_CONFIG_INVALID_VALUE EZSP_CONFIG_INVALID_TAG EZSP_CONFIG_INVALID_CALL
Table 28.
EzspPolicyId
Structure F ield 0x00 0x01 0x02 Description Controls trust center behavior. Controls how external binding modification requests are handled. Controls whether the Host supplies datagram replies.
EZSP_TRUST_CENTER_POLICY EZSP_BINDING_MODIFICATION_POLICY EZSP_DATAGRAM_REPLIES_POLICY
43/88
EmberZNet serial protocol Table 28. EzspPolicyId (continued)
Structure EZSP_POLL_HANDLER_POLICY EZSP_MESSAGE_CONTENTS_IN_CALLBACK _POLICY F ield 0x03 0x04 Description Controls whether pollHandler callbacks are generated.
SN260
Controls whether the message contents are included in unicastSent and messageSent callbacks.
Table 29.
EzspDecisionId
Structure F ield 0x00 Description EZSP_TRUST_CENTER_POLICY default decision. Only allow nodes that are joining securely using the network key to join. EZSP_TRUST_CENTER_POLICY decision. Allow all nodes to join, sending the key to nodes that are not joining securely. EZSP_TRUST_CENTER_POLICY decision. Reject all join attempts. EZSP_TRUST_CENTER_POLICY decision. Forward the request to the trust center (this value should not be used for the trust center itself). EZSP_BINDING_MODIFICATION_POLICY default decision. Do not allow the local binding table to be changed by remote nodes. EZSP_BINDING_MODIFICATION_POLICY decision. Allow remote nodes to change the local binding table. EZSP_DATAGRAM_REPLIES_POLICY default decision. The SN260 will automatically send an empty reply (containing no payload) for every datagram received. EZSP_DATAGRAM_REPLIES_POLICY decision. The SN260 will only send a reply if it receives a sendReply command from the Host. EZSP_POLL_HANDLER_POLICY default decision. Do not inform the Host when a child polls. EZSP_POLL_HANDLER_POLICY decision. Generate a pollHandler callback when a child polls. EZSP_MESSAGE_CONTENTS_IN_CALLBACK_POLICY default decision. Include only the message tag in unicastSent and messageSent callbacks. EZSP_MESSAGE_CONTENTS_IN_CALLBACK_POLICY decision. Include both the message tag and the message contents in unicastSent and messageSent callbacks.
EZSP_ALLOW_SECURE_JOINS_ONLY
EZSP_ALLOW_ALL_JOINS
0x01
EZSP_DISALLOW_ALL_JOINS
0x02
EZSP_ASK_TRUST_CENTER
0x03
EZSP_DISALLOW_BINDING_MODIFICATIO N EZSP_ALLOW_BINDING_MODIFICATION
0x10
0x11
EZSP_HOST_WILL_NOT_SUPPLY_REPLY
0x20
EZSP_HOST_WILL_SUPPLY_REPLY
0x21
EZSP_POLL_HANDLER_IGNORE EZSP_POLL_HANDLER_CALLBACK
0x30 0x31
EZSP_MESSAGE_TAG_ONLY_IN_CALLBACK
0x40
EZSP_MESSAGE_TAG_AND_CONTENTS_IN_ CALLBACK
0x41
44/88
SN260 Table 30. EmberStatus
Structure EMBER_SUCCESS EMBER_ERR_FATAL EMBER_EEPROM_MFG_STACK_VERSION_ MISMATCH EMBER_INCOMPATIBLE_STATIC_MEMORY_ DEFINITIONS EMBER_EEPROM_MFG_VERSION_MISMATCH EMBER_EEPROM_STACK_VERSION_ MISMATCH EMBER_NO_BUFFERS EMBER_SERIAL_INVALID_BAUD_RATE EMBER_SERIAL_INVALID_PORT EMBER_SERIAL_TX_OVERFLOW EMBER_SERIAL_RX_OVERFLOW EMBER_SERIAL_RX_FRAME_ERROR EMBER_SERIAL_RX_PARITY_ERROR EMBER_SERIAL_RX_EMPTY EMBER_SERIAL_RX_OVERRUN_ERROR EMBER_MAC_TRANSMIT_QUEUE_FULL EMBER_MAC_UNKNOWN_HEADER_TYPE EMBER_MAC_SCANNING EMBER_MAC_NO_DATA EMBER_MAC_JOINED_NETWORK EMBER_MAC_BAD_SCAN_DURATION EMBER_MAC_INCORRECT_SCAN_TYPE EMBER_MAC_INVALID_CHANNEL_MASK EMBER_MAC_COMMAND_TRANSMIT_ FAILURE EMBER_MAC_NO_ACK_RECEIVED EMBER_MAC_INDIRECT_TIMEOUT F ield 0x00 0x01 0x04
EmberZNet serial protocol
Description Generic 'no error' message. Generic 'fatal error' message. Manufacturing and stack token format in non-volatile memory is different than what the stack expects (returned at initialization). Static memory definitions in ember-static-memory.h are incompatible with this stack version. Manufacturing token format in non-volatile memory is different than what the stack expects (returned at initialization). Stack token format in non-volatile memory is different than what the stack expects (returned at initialization). There are no more buffers. Specified an invalid baud rate. Specified an invalid serial port. Tried to send too much data. There was not enough space to store a received character and the character was dropped. Detected a UART framing error. Detected a UART parity error. There is no received data to process. Receive interrupt was not handled in time, and a character was dropped. MAC transmit queue is full. MAC header FCR error on receive. MAC can't complete this task because it is scanning. No pending data exists for device doing a data poll. Attempt to scan when we are joined to a network. Scan duration must be 0 to 14 inclusive. Attempt was made to scan with an incorrect duration value. emberStar tScan was called with an incorrect scan type. emberStar tScan was called with an invalid channel mask. Failed to scan current channel because we were unable to transmit the relevant MAC command. We expected to receive an ACK following the transmission, but the MAC level ACK was never received. Indirect data message timed out before polled.
0x05
0x06
0x07 0x18 0x20 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x39 0x3A 0x3D 0x31 0x32 0x33 0x34 0x35 0x36
0x40 0x42
45/88
EmberZNet serial protocol Table 30. EmberStatus (continued)
Structure F ield Description
SN260
EMBER_SIM_EEPROM_ERASE_PAGE_GREEN
0x43
Simulated EEPROM is telling the application that there is at least one flash page to be erased. GREEN status means the current page has not filled above the ERASE_CRITICAL_THRESHOLD. The application should call the function halSimEepromErasePage() when it can to erase a page. Simulated EEPROM is telling the application that there is at least one flash page to be erased. RED status means the current page has filled above the ERASE_CRITICAL_THRESHOLD. Due to the shrinking availability of write space, there is a danger of data loss. The application must call the function halSimEepromErasePage() as soon as possible to erase a page. Simulated EEPROM has run out of room to write any new data and the data trying to be set has been lost. This error code is the result of ignoring the SIM_EEPROM_ERASE_PAGE_RED error code. The application must call the function halSimEepromErasePage() to make room for any further calls to set a token. A fatal error has occurred while trying to write data to the Flash and the write verification has failed. The data in the flash cannot be trusted after this error, and it is possible this error is the result of exceeding the life cycles of the flash. Attempt 1 to initialize the simulated EEPROM has failed. This failure means the information already stored in Flash (or a lack thereof), is fatally incompatible with the token information compiled into the code image being run. Attempt 2 to initialize the simulated EEPROM has failed. This failure means Attempt 1 failed, and the token system failed to properly reload default tokens and reset the simulated EEPROM. Attempt 3 to initialize the simulated EEPROM has failed. This failure means one or both of the tokens TOKEN_MFG_NVDATA_VERSION or TOKEN_STACK_NVDATA_VERSION were incorrect and the token system failed to properly reload default tokens and reset the simulated EEPROM. An unknown flash token was specified. Could not create new flash token because it already exists. An incorrect size was specified when retrieving token data. Couldn't write token because it is marked read-only. Bootloader received an invalid message (failed attempt to go into bootloader).
EMBER_SIM_EEPROM_ERASE_PAGE_RED
0x44
EMBER_SIM_EEPROM_FULL
0x45
EMBER_SIM_EEPROM_FLASH_WRITE_ FAILED
0x46
EMBER_SIM_EEPROM_INIT_1_FAILED
0x47
EMBER_SIM_EEPROM_INIT_2_FAILED
0x48
EMBER_SIM_EEPROM_INIT_3_FAILED
0x49
EMBER_ERR_TOKEN_UNKNOWN EMBER_ERR_TOKEN_EXISTS EMBER_ERR_TOKEN_INVALID_SIZE EMBER_ERR_TOKEN_READ_ONLY EMBER_ERR_BOOTLOADER_TRAP_ TABLE_BAD
0x4B 0x4C 0x4D 0x4E 0x58
46/88
SN260 Table 30. EmberStatus (continued)
Structure EMBER_ERR_BOOTLOADER_TRAP_UNKNOWN F ield 0x59
EmberZNet serial protocol
Description Bootloader received an invalid message (failed attempt to go into bootloader). Bootloader cannot complete the bootload operation because either an image was not found or the image exceeded memory bounds. EMBER_TRANSPORT_CONNECTION_COUNT limit has been reached. A connection has either been opened or is already open. A connection experienced a catastrophic error. The connection is now closed and messages may have been lost. Transpor t layer successfully closed a connection. Transpor t layer is in process of closing a connection (waiting for a response from the remote device). Transpor t layer attempted to send or deliver a message, but it failed. This binding index is out of range of the current binding table. Could not set or find a binding index given the specified terminal. An invalid binding table index was given to a function. Multiple binding table entries were found for the specified terminal. API call is not allowed given the current state of the stack (for example, opening a connection from a sleepy node.). Link cost to a node is not known. Maximum number of in-flight messages (such as EMBER_TRANSPORT_PACKET_COUNT) has been reached. A connection is not open yet. Message to be transmitted is too big to fit into a single over-the-air packet. Application is trying to delete or overwrite a binding that is in use. EUI64 is not available in the current packet. One or more sequenced messages failed to be received. Conversion is complete. Conversion cannot be done because a request is being processed. Conversion is deferred until the current request has been processed. No results are pending.
EMBER_ERR_BOOTLOADER_NO_IMAGE
0x5A
EMBER_TOO_MANY_CONNECTIONS EMBER_CONNECTION_OPEN EMBER_CONNECTION_FAILED EMBER_CONNECTION_CLOSED EMBER_CONNECTION_CLOSING EMBER_DELIVERY_FAILED EMBER_BINDING_INDEX_OUT_OF_RANGE EMBER_INVALID_BINDING_TERMINAL EMBER_INVALID_BINDING_INDEX EMBER_TERMINAL_HAS_MULTIPLE_ BINDINGS EMBER_INVALID_CALL EMBER_COST_NOT_KNOWN EMBER_MAX_MESSAGE_LIMIT_REACHED EMBER_CONNECTION_NOT_YET_OPEN EMBER_MESSAGE_TOO_LONG EMBER_BINDING_IS_ACTIVE EMBER_EUI64_NOT_AVAILABLE EMBER_INCOMING_SEQUENCED_MESSAGES LOST EMBER_ADC_CONVERSION_DONE EMBER_ADC_CONVERSION_BUSY EMBER_ADC_CONVERSION_DEFERRED EMBER_ADC_NO_CONVERSION_PENDING
0x60 0x61 0x63 0x64 0x65 0x66 0x69 0x6B 0x6C 0x6F 0x70 0x71 0x72 0x73 0x74 0x75 0x76 0x77 0x80 0x81 0x82 0x84
47/88
EmberZNet serial protocol Table 30. EmberStatus (continued)
Structure EMBER_SLEEP_INTERRUPTED EMBER_PHY_TX_UNDERFLOW EMBER_PHY_TX_INCOMPLETE EMBER_PHY_INVALID_CHANNEL EMBER_PHY_INVALID_POWER EMBER_PHY_TX_BUSY F ield 0x85 0x88 0x89 0x8A 0x8B 0x8C Description Sleeping (for a duration) has been abnormally interrupted and exited prematurely. Transmit hardware buffer underflowed.
SN260
Transmit hardware did not finish transmitting a packet. An unsupported channel setting was specified. An unsupported power setting was specified. Packet cannot be transmitted because the physical MAC layer is currently transmitting a packet. (This is used for the MAC backoff algorithm.) The software installed on the hardware doesn't recognize the hardware radio type. The software installed on the hardware doesn't recognize the hardware radio type. PHY did not receive the entire packet it was expecting from the radio. Stack software has completed initialization and is ready to send and receive packets over the air. Network is not operating. Network has activity pending and should not be shut down. Node has not joined a network. An attempt to join a network failed. The chosen security level (the value of EMBER_SECURITY_LEVEL) is not supported by the stack. After moving, a mobile node's attempt to re-establish contact with the network failed. A message cannot be sent because the network is currently overloaded. A datagram was sent to a node and the EUI64 address in the datagram did not match the node's EUI64 address. The NodeId was invalid. The application tried to send a message using an endpoint that it has not defined. The application tried to use a binding that has been remotely modified and the change has not yet been reported to the application. A critical and fatal error indicating that the version of the stack trying to run does not match with the chip it is running on. The software (stack) on the chip must be replaced with software that is compatible with the chip.
EMBER_PHY_UNKNOWN_RADIO_TYPE EMBER_PHY_OSCILLATOR_CHECK_FAILED EMBER_PHY_PARTIAL_PACKET EMBER_NETWORK_UP EMBER_NETWORK_DOWN EMBER_NETWORK_PENDING_ACTIVITY EMBER_NOT_JOINED EMBER_JOIN_FAILED EMBER_INVALID_SECURITY_LEVEL
0x8D 0x8E 0x8F 0x90 0x91 0x92 0x93 0x94 0x95
EMBER_MOVE_FAILED EMBER_NETWORK_BUSY
0x96 0xA1
EMBER_NODEID_INVALID
0xA2
EMBER_INVALID_ENDPOINT
0xA3
EMBER_BINDING_HAS_CHANGED
0xA4
EMBER_STACK_AND_HARDWARE_MISMATCH
0xB0
48/88
SN260 Table 31. EmberEventUnits
Structure EMBER_EVENT_INACTIVE EMBER_EVENT_MS_TIME EMBER_EVENT_QS_TIME EMBER_EVENT_MINUTE_TIME F ield 0x00 0x01 0x02 0x03
EmberZNet serial protocol
Description Event is not scheduled to run. Execution time is in approximate milliseconds. Execution time is in 'binary' quarter seconds (256 approximate milliseconds each). Execution time is in 'binary' minutes (65536 approximate milliseconds each).
Table 32.
EmberNodeType
Structure F ield 0x01 0x02 0x03 0x04 0x05 Description Will relay messages and can act as a parent to other nodes. Will relay messages and can act as a parent to other nodes. Communicates only with its parent and will not relay messages. An end device whose radio can be turned off to save power. The application must poll to receive messages. A sleepy end device that can move through the network.
EMBER_COORDINATOR EMBER_ROUTER EMBER_END_DEVICE EMBER_SLEEPY_END_DEVICE EMBER_MOBILE_END_DEVICE
Table 33.
EmberNetworkStatus
Structure F ield 0x00 0x01 0x02 0x03 0x04 Description The node is not associated with a network in any way. The node is currently attempting to join a network. The node is joined to a network. The node is an end device joined to a network but its parent is not responding. The node is in the process of leaving its current network.
EMBER_NO_NETWORK EMBER_JOINING_NETWORK EMBER_JOINED_NETWORK EMBER_JOINED_NETWORK_NO_PARENT EMBER_LEAVING_NETWORK
Table 34.
EmberIncomingMessageType
Structure F ield 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 Datagram. Datagram reply. Sequenced message. Multicast. Shared multicast. Multicast loopback. Unicast. Broadcast. Description
EMBER_INCOMING_DATAGRAM EMBER_INCOMING_DATAGRAM_REPLY EMBER_INCOMING_SEQUENCED EMBER_INCOMING_MULTICAST EMBER_INCOMING_SHARED_MULTICAST EMBER_INCOMING_MULTICAST_LOOPBACK 333EMBER_INCOMING_UNICAST EMBER_INCOMING_BROADCAST
49/88
EmberZNet serial protocol Table 35. EmberBindingType
Structure EMBER_UNUSED_BINDING EMBER_UNICAST_BINDING EMBER_AGGREGATION_BINDING F ield 0x00 0x01 0x02 Description A binding that is currently not in use. A unicast binding whose 64-bit identifier is the destination EUI64. A unicast binding whose 64-bit identifier is the aggregator EUI64.
SN260
EMBER_MULTICAST_BINDING
0x03
A multicast binding whose 64-bit identifier is the group address. A multicast binding can be used to send messages to the group and to receive messages sent to the group.
Table 36.
EmberUnicastOption Structure F ield 0x00 0x04 0x10 0x40 0x80 0x20 0x01 No options. Reser ved. Reser ved. Resend the message using the APS retry mechanism. Causes a route discovery to be initiated if no route to the destination is known. Causes a route discovery to be initiated even if one is known. Reser ved. Description
EMBER_UNICAST_OPTION_NONE EMBER_UNICAST_OPTION_APS_INDIRECT EMBER_UNICAST_OPTION_HAVE_SOURCE EMBER_UNICAST_OPTION_APS_RETRY EMBER_UNICAST_OPTION_ENABLE_ROUTE DISCOVERY EMBER_UNICAST_OPTION_FORCE_ROUTE_ DISCOVERY EMBER_UNICAST_OPTION_POLL_ RESPONSE
Table 37.
EmberNetworkScanType
Structure F ield 0x00 0x01 Description An energy scan scans each channel for its RSSI value. An active scan scans each channel for available networks.
EMBER_ENERGY_SCAN EMBER_ACTIVE_SCAN
Table 38.
EmberJoinDecision
Structure F ield 0x00 0x01 0x02 0x03 Description Allow the node to join. The node has the key. Allow the node to join. Send the key to the node. Deny join. Ask the trust center.
EMBER_HAS_KEY EMBER_SEND_KEY EMBER_DENY_JOIN EMBER_ASK_TRUST_CENTER
50/88
SN260
EmberZNet serial protocol
7.3.4
Table 39.
Configuration frames
version
ID: 0x00
Name: version
Description: The command allows the Host to specify the desired EZSP version. This document describes version 1 of the protocol. The response provides information about the firmware running on the SN260. Command parameters: int8u desiredProtocolVersion Response parameters: int8u protocolVersion The EZSP version the SN260 is using. If the SN260 does not support the version requested by the Host, it will use the highest version it does support. The type of stack running on the SN260. The available EZSP commands and their parameters depend on the stack type. The mesh stack is type 2. The version number of the stack. The EZSP version the Host wishes to use.
int8u stackType int16u stackVersion
Table 40.
getConfigurationValue
ID: 0x52
Name: getConfigurationValue
Description: Reads a configuration value from the SN260. Command parameters: EzspConfigId configId Response parameters: EzspConfigStatus status int16u value EZSP_CONFIG_SUCCESS if the value was read successfully, EZSP_CONFIG_INVALID_ID if the SN260 does not recognize configId. The configuration value. Identifies which configuration value to read.
Table 41.
setConfigurationValue
ID: 0x53
Name: setConfigurationValue
Description: Writes a configuration value to the SN260. Configuration values can be modified by the Host after the SN260 has reset. After the stack status changes to EMBER_NETWORK_UP, configuration values can no longer be modified and this command will respond with EZSP_CONFIG_INVALID_CALL. Command parameters: EzspConfigId configId int16u value Response parameters: EZSP_CONFIG_SUCCESS if the configuration value was changed, EZSP_CONFIG_OUT_OF_MEMORY if the new value exceeded the available memory, EZSP_CONFIG_INVALID_VALUE if the new value was out of bounds, EZSP_CONFIG_INVALID_ID if the SN260 does not recognize configId, EZSP_CONFIG_INVALID_CALL if configuration values can no longer be modified. Identifies which configuration value to change. The new configuration value.
EzspConfigStatus status
51/88
EmberZNet serial protocol Table 42. addEndpoint
ID: 0x02
SN260
Name: addEndpoint
Description: Configures endpoint information on the SN260. The SN260 does not remember these settings after a reset. Endpoints can be added by the Host after the SN260 has reset. After the stack status changes to EMBER_NETWORK_UP, endpoints can no longer be added and this command will respond with EZSP_CONFIG_INVALID_CALL. Command parameters: int8u endpoint int16u profileId int16u deviceId int8u appFlags int8u inputClusterCount int8u outputClusterCount int8u[] inputClusterList int8u[] outputClusterList Response parameters: EZSP_CONFIG_SUCCESS if the endpoint was added, EZSP_CONFIG_OUT_OF_MEMORY if there is not enough memory available to add the endpoint, EZSP_CONFIG_INVALID_VALUE if the endpoint already exists, EZSP_CONFIG_INVALID_CALL if endpoints can no longer be added. The application endpoint to be added. The endpoint's application profile. The endpoint's device ID within the application profile. The device version and flags indicating description availability. The number of input clusters. The number of output clusters. Input cluster IDs the endpoint will accept. Output cluster IDs the endpoint may send.
EzspConfigStatus status
Table 43.
setPolicy
ID: 0x55
Name: setPolicy
Description: Allows the Host to change the policies used by the SN260 to make fast decisions. Command parameters: EzspPolicyId policyId EzspDecisionId decisionId Response parameters: EzspConfigStatus status EZSP_CONFIG_SUCCESS if the policy was changed, EZSP_CONFIG_INVALID_ID if the SN260 does not recognize policyId. Identifies which policy to modify. The new decision for the specified policy.
Table 44.
getPolicy
ID: 0x56
Name: getPolicy
Description: Allows the Host to read the policies used by the SN260 to make fast decisions. Command parameters: EzspPolicyId policyId Identifies which policy to read.
52/88
SN260 Table 44. getPolicy (continued)
EmberZNet serial protocol
Response parameters: EzspConfigStatus status EzspDecisionId decisionId EZSP_CONFIG_SUCCESS if the policy was read successfully, EZSP_CONFIG_INVALID_ID if the SN260 does not recognize policyId. The current decision for the specified policy.
7.3.5
Table 45.
Name: nop
Utilities frames
nop
ID: 0x05
Description: A transaction which does nothing. The Host can use this to set the sleep mode or to check the status of the SN260. Command parameters: None Response parameters: None
Table 46.
invalidCommand
ID: 0x58
Name: invalidCommand
Description: Indicates that the SN260 received a command containing an unsupported frame ID. This frame is a response to an invalid command. Response parameters: None
Table 47.
callback
ID: 0x06
Name: callback
Description: Allows the SN260 to respond with a pending callback. Command parameters: None The response to this command can be any of the callback responses.
Table 48.
noCallbacks
ID: 0x07
Name: noCallbacks
Description: Indicates that there are currently no pending callbacks. This frame is a response to the callback command. Response parameters: None
Table 49.
Name: reset
reset
ID: 0x08
Description: Allows the Host to reset the SN260. Command parameters: None Response parameters: None
53/88
EmberZNet serial protocol Table 50. setToken
ID: 0x09
SN260
Name: setToken
Description: Sets a token (8 bytes of non-volatile storage) in the simulated EEPROM of the SN260. Command parameters: int8u tokenId int8u[8] tokenData Response parameters: EmberStatus status An EmberStatus value indicating success or the reason for failure. Which token to set (0 to 7). The data to write to the token.
Table 51.
getToken
ID: 0x0A
Name: getToken
Description: Retrieves a token (8 bytes of non-volatile storage) from the simulated EEPROM of the SN260. Command parameters: int8u tokenId Response parameters: EmberStatus status int8u[8] tokenData An EmberStatus value indicating success or the reason for failure. The contents of the token. Which token to read (0 to 7).
Table 52.
getMfgToken
ID: 0x0B
Name: getMfgToken
Description: Retrieves a manufacturing token (8 bytes of non-volatile storage) from the Flash Information Area of the SN260. Command parameters: int8u tokenId Response parameters: EmberStatus status int8u[8] tokenData An EmberStatus value indicating success or the reason for failure. The contents of the manufacturing token. Which manufacturing token to read (0 to 7).
Table 53.
setRam
ID: 0x46
Name: setRam
Description: Writes data supplied by the Host to RAM in the SN260. The amount of RAM available for use by the Host must be set using the setConfigurationValue command. parameters int8u startIndex int8u dataLength int8u[] data Response parameters: EmberStatus status An EmberStatus value indicating success or the reason for failure. The location to start writing the data. The length |
