ZigBee® 802.15.4 network processor Integrated 2.4GHz, IEEE 802.15

The Datasheet Archive - 100 Million Datasheets from 7500 Manufacturers.

ZigBee® 802.15.4 network processor Integrated 2.4GHz, IEEE 802.15

Datasheet Thumbnail

Top Searches for this datasheet

SN260
ZigBee® 802.15.4 network processor
Integrated 2.4GHz, IEEE 802.15.4-compliant transceiver: Robust filtering allows co-existence with IEEE 802.11g Bluetooth devices sensitivity PER, 20-byte packet) +2.5 nominal output power Increased radio performance mode (Boost mode) gives -100 sensitivity +4.5 transmit power Integrated loop filter Secondary TX-only port applications requiring external Integrated IEEE 802.15.4 Dedicated peripherals integrated memory Ember ZigBee®-compliant stack running dedicated network processor
Controlled Host using EmberZNetSerial Protocol (EZSP) Standard UART interfaces allow connection variety Host microcontrollers Non-intrusive debug interface (SIF) Integrated hardware software support InSightDevelopment Environment Provides integrated oscillator power operation Three sleep modes: Processor idle (automatic) Deep sleep-1.0µA Power down-1.0µA Watchdog timer power-on-reset circuitry Integrated encryption accelerator Integrated 1.8V voltage regulator
March 2009
1/47
www.st.com
Contents
SN260
Contents
Abbreviations acronyms References General description assignment Top-level functional description Functional description
Receive (RX) path
6.1.1 6.1.2 baseband RSSI
Transmit (TX) path
6.2.1 6.2.2 baseband TX_ACTIVE signal
Integrated module Packet trace interface (PTI) 16-bit microprocessor Embedded memory
6.6.1 6.6.2 Simulated EEPROM Flash information area (FIA)
6.10 6.11
Encryption accelerator nRESET signal Reset detection Power-on-reset (POR) Clock sources
6.11.1 6.11.2 High-frequency crystal oscillator Internal oscillator
6.12 6.13 6.14
Random number generator Watchdog timer Sleep timer
2/47
SN260
Contents
6.15
Power management
protocol
Physical interface configuration transaction
7.2.1 7.2.2 7.2.3 7.2.4 7.2.5 7.2.6 7.2.7 Command section Wait section Response section Asynchronous signaling Spacing Waking SN260 from sleep Error conditions
protocol timing Data format byte
7.5.1 7.5.2 Primary bytes Special response bytes
Powering power cycling, rebooting
7.6.1 7.6.2 Bootloading SN260 Unexpected resets
Transaction examples
7.7.1 7.7.2 7.7.3 7.7.4 protocol version EmberZNet serial protocol frame Version command SN260 reset Three-part transaction: Wake, Version, Stack Status Callback
UART Gateway Protocol module programming debug interface Typical application Package mechanical data Ordering information Electrical characteristics
3/47
Contents
SN260
13.1 13.2 13.3 13.4 13.5 13.6
Absolute maximum ratings Recommended operating conditions Environmental characteristics electrical characteristics Digital specifications electrical characteristics
13.6.1 13.6.2 13.6.3 Receive Transmit Synthesizer
Revision history
4/47
SN260
Abbreviations acronyms
Abbreviations acronyms
Table Abbreviations acronyms
Meaning Adjacent Channel Rejection Advanced Encryption Standard Cipher Block Chaining-Message Authentication Code Clear Channel Assessment Counter with CBC-MAC Mode encryption Improved Counter with CBC-MAC Mode encryption Carrier Sense Multiple Access Counter Mode Electrically Erasable Programmable Read Only Memory Electro Static Discharge Equivalent Series Resistance Full Function Device (ZigBee) Flash Information Area General Purpose (pins) High Frequency MHz) Inter-Integrated Circuit Integrated Development Environment Intermediate Frequency Third order Intermodulation Product Interrupt Service Routine Kilobyte kilobits/second Frequency Noise Amplifier Link Quality Indicator Medium Access Control Moisture Sensitivity Level Mega samples second Offset-Quadrature Phase Shift Keying Power Amplifier Packet Error Rate Physical Layer Phase-Locked Loop Power-On-Reset Power Spectral Density Power Supply Rejection Ratio Packet Trace Interface CBC-MAC CCM* CSMA EEPROM GPIO kbps Msps O-QPSK PSRR
Acronym/abbreviation
5/47
References Table Abbreviations acronyms (continued)
Meaning Pulse Width Modulation Restriction Hazardous Substances Receive Signal Strength Indicator Start Frame Delimiter Serial Interface Serial Peripheral Interface Universal Asynchronous Receiver/Transmitter Voltage Controlled Oscillator Voltage Supply RoHS RSSI UART
SN260
Acronym/abbreviation
References
ZigBee Specification (www.zigbee.org; ZigBee document 053474) ZigBee-PRO Stack Profile (www.zigbee.org; ZigBee document 074855) ZigBee Stack Profile (www.zigbee.org; ZigBee document 064321) Bluetooth Core Specification v2.1 IEEE 802.15.4-2003 IEEE 802.11g Ember EM260 Reference Design
6/47
SN260
General description
General description
SN260 integrates 2.4GHz, IEEE 802.15.4-compliant transceiver with 16-bit network processor (XAP2b core) EmberZNetTM, Ember ZigBee-compliant network stack. SN260 exposes access EmberZNet across standard module UART module, allowing application development Host platform. This means that SN260 viewed ZigBee peripheral connected over serial interface. XAP2b microprocessor power-optimized core integrated SN260. contains integrated Flash memory along with optimized peripheral enhance operation network stack. transceiver utilizes efficient architecture that exceeds dynamic range requirements imposed IEEE 802.15.4-2003 standard over 15dB. integrated receive channel filtering allows co-existence with other communication standards 2.4GHz spectrum such IEEE 802.11g Bluetooth. integrated regulator, VCO, loop filter, power amplifier keep external component count low. optional highperformance radio mode (boost mode) software selectable boost dynamic range further 3dB. SN260 contains embedded Flash integrated program data storage. employing effective wear-leveling algorithm, stack optimizes lifetime embedded Flash, affords application ability configure stack application tokens within SN260. maintain strict timing requirements imposed ZigBee IEEE 802.15.4-2003 standard, SN260 integrates number functions into hardware. hardware handles automatic transmission reception, automatic backoff delay, clear channel assessment transmission, well automatic filtering received packets. addition, SN260 allows true level debugging integrating Packet Trace Interface. integrated voltage regulator, power-on-reset circuitry, sleep timer, low-power sleep modes available. deep sleep power down modes draw less than allowing products achieve long battery life. Finally, SN260 utilizes non-intrusive module powerful software debugging programming network processor. Target applications SN260 include:
Building automation control Home automation control Home entertainment control Asset tracking
SN260 only purchased with EmberZNet stack. This technical datasheet describes SN260 features available customers using with EmberZNet stack.
7/47
assignment
SN260
assignment
Figure SN260 assignment protocol
SN260
8/47
SN260 Figure SN260 assignment UART protocol
assignment
SN260
Table
descriptions
Signal VDD_VCO RF_P RF_N VDD_RF RF_TX_ALT_P RF_TX_ALT_N VDD_IF BIAS_R VDD_PADSA Direction Power Power Power Power 1.8V supply Differential (with RF_N) receiver input/transmitter output Differential (with RF_P) receiver input/transmitter output 1.8V supply (LNA Differential (with RF_TX_ALT_N) transmitter output (optional) Differential (with RF_TX_ALT_P) transmitter output (optional) 1.8V supply (mixers filters) Bias setting resistor Analog supply (1.8V) Logic-level control external RX/TX switch SN260 baseband controls TX_ACTIVE drives high (1.8V) when mode. (Refer Table section TX_ACTIVE signal.) Active chip reset (internal pull-up) Regulator output (1.8V) Pads supply (2.1 3.6V) 1.8V digital core supply Description
TX_ACTIVE
nRESET VREG_OUT VDD_PADS VDD_CORE
Power Power Power
9/47
assignment Table
SN260
descriptions (continued)
Signal nSSEL_INT Direction Description Slave Select Interrupt (from Host SN260) This signal must connected nSSEL (Pin UART Clear Send (enables SN260 transmission) When using UART interface, this signal should left unconnected used. When using interface, this signal left connected. UART Request Send (enables Host transmission) When using UART interface, this signal should left unconnected used. Data, Master Slave (from Host SN260) When using UART interface, this signal left connected. Data, Master Slave (from SN260 Host) When using UART interface, this signal left connected. Pads supply (2.1 3.6V) Clock (from Host SN260) When using UART interface, this signal left connected. Slave Select (from Host SN260) When using UART interface, this signal left connected. Frame signal Packet Trace Interface (PTI) Data signal Packet Trace Interface (PTI) Pads supply (2.1 3.6V) When using interface, this signal left connected. UART Transmitted Data (from SN260 Host) Host Interrupt signal (from SN260 Host) UART Received Data (from Host SN260) Programming Debug Interface, Clock (internal pull down) Programming Debug Interface, Master Slave Programming Debug Interface, Master Slave (external pull-down re-quired guarantee state Deep Sleep Mode) Programming Debug Interface, load strobe (open collector with internal pull Ground supply 1.8V Flash memory supply Spare Debug signal Link Activity signal Wake Interrupt signal (from Host SN260) When using UART interface, this signal left connected. 1.8V digital core supply 1.8V synthesizer pre-scalar supply
nCTS N.C. nRTS MOSI N.C. MISO N.C. VDD_PADS SCLK N.C. nSSEL N.C. PTI_EN PTI_DATA VDD_PADS N.C. nHOST_INT SIF_CLK SIF_MISO SIF_MOSI nSIF_LOAD VDD_FLASH SDBG LINK_ACTIVITY nWAKE N.C. VDD_CORE VDD_SYNTH_PRE Power Power Power Power Power Power
10/47
SN260 Table
OSCB OSCA VDD_24MHZ
assignment descriptions (continued)
Signal Direction Power Ground Description 24MHz crystal oscillator left open when using external clock input OSCA 24MHz crystal oscillator external clock input 1.8V high-frequency oscillator supply Ground supply bottom center package forms (see SN260 Reference Design considerations)
11/47
Top-level functional description
SN260
Top-level functional description
Figure shows detailed block diagram SN260. Figure SN260 block diagram
radio receiver low-IF, super-heterodyne receiver. utilizes differential signal paths minimize noise interference, architecture been chosen optimize coexistence with other devices within 2.4GHz band (namely, IEEE 802.11g Bluetooth). After amplification mixing, signal filtered combined prior being sampled ADC. digital receiver implements coherent demodulator generate chip stream hardware-based MAC. addition, digital receiver contains analog radio calibration routines control gain within receiver path. radio transmitter utilizes efficient architecture which data stream directly modulates VCO. integrated boosts output power. calibration path well output power controlled digital logic. SN260 used with external TX_ACTIVE signal should used control timing external switching logic. integrated loop filter minimize off-chip circuitry. Only 24MHz crystal with loading capacitors required properly establish reference signal. interfaces data memory baseband modules. provides hardware-based IEEE 802.15.4 packet-level filtering. supplies accurate symbol time base that minimizes synchronization effort software stack meets protocol timing requirements. addition, provides timer synchronization assistance IEEE 802.15.4 CSMA-CA algorithm.
12/47
SN260
Top-level functional description SN260 integrates hardware support Packet Trace module, which allows robust packet-based debug. This element critical component InSight Desktop, Ember software IDE, providing advanced network debug capability when coupled with InSight Adapter. SN260 integrates 16-bit XAP2b microprocessor developed Cambridge Consultants Ltd. This power-efficient, industry-proven core provides appropriate level processing power meet needs Ember ZigBee-compliant stack, EmberZNet. addition, module provides non-intrusive programming debug interface allowing real-time application debugging. SN260 exposes Ember Serial over either UART interface, which allows application development occur Host platform choice. interface uses four standard signals plus additional signals, nHOST_INT nWAKE, which provide easy-to-use handshake mechanism between Host SN260. UART interface uses standard UART signals also supports either standard RTS/CTS XON/XOFF flow control. integrated voltage regulator generates regulated 1.8V reference voltage from unregulated supply voltage. This voltage decoupled routed externally supply 1.8V core logic. addition, integrated module allows proper cold start SN260. SN260 contains high-frequency MHz) crystal oscillator and, low-power operation, second low-frequency internal oscillator. SN260 contains power domains. always-powered High Voltage Supply used powering GPIO pads critical chip functions. rest chip powered regulated Voltage Supply which disabled during deep sleep reduce power consumption.
13/47
Functional description
SN260
Functional description
SN260 connects Host platform through either standard interface standard UART interface. EmberZNet Serial Protocol (EZSP) been defined allow application written host platform choice. Therefore, SN260 comes with license EmberZNet, Ember ZigBee-compliant software stack. following brief description hardware modules provides necessary background operation SN260. more information, contact your local sales representative.
Receive (RX) path
SN260 path spans analog digital domains. architecture based low-IF, super-heterodyne receiver. utilizes differential signal paths minimize noise interference. input signal mixed down frequency 4MHz mixers. output mixers filtered combined prior being sampled 12Msps ADC. filtering within path been designed optimize coexistence SN260 with other 2.4GHz transceivers, such IEEE 802.11g Bluetooth.
6.1.1
baseband
SN260 baseband (within digital domain) implements coherent demodulator optimal performance. baseband demodulates O-QPSK signal chip level synchronizes with IEEE 802.15.4-2003 preamble. automatic gain control (AGC) module adjusts analog gain continuously (every symbol) until preamble detected. Once packet preamble detected, gain fixed during packet reception. baseband de-spreads demodulated data into 4-bit symbols. These symbols buffered passed hardware-based module filtering. addition, baseband provides calibration control interface analog modules, including LNA, Baseband Filter, modulation modules. EmberZNet software includes calibration algorithms which this interface reduce effects process temperature variation.
6.1.2
RSSI
SN260 calculates RSSI over 8-symbol period well received packet. utilizes gain settings output level within algorithm. linear range RSSI specified 40dB over temperatures. room temperature, linear range approximately 60dB (-90 -30dBm). SN260 baseband provides support IEEE 802.15.4-2003 required methods summarized Table Modes defined 802.15.4-2003 standard; Mode proprietary mode.
14/47
SN260 Table
mode
Functional description mode behavior
Mode behavior Clear channel reports busy medium either carrier sense RSSI exceeds their thresholds. Clear channel reports busy medium RSSI exceeds threshold. Clear channel reports busy medium carrier sense exceeds threshold. Clear channel reports busy medium both RSSI carrier sense exceed their thresholds.
EmberZNet Software Stack sets Mode, configurable Application Layer. software versions beginning with EmberZNet 2.5.4, Mode used, busy channel reported RSSI exceeds threshold. software versions prior 2.5.4, Mode input powers higher than dBm, there some compression receive chain where gain properly adjusted. worst case, this resulted packet loss 0.1%. This packet loss seen range testing measurements when nodes closely positioned transmitting high power when receiving from test equipment. There damage SN260 from this problem. This issue will rarely occur field ZigBee Nodes will spaced enough apart. nodes close enough occur field, networking software treat packet having been received therefore level network level retries resolve problem without needing notify upper level application.
Transmit (TX) path
SN260 transmitter utilizes both analog circuitry digital logic produce O-QPSK modulated signal. area-efficient architecture directly modulates spread symbols prior transmission. differential signal paths increase noise immunity provide common interface external balun.
6.2.1
baseband
SN260 baseband (within digital domain) performs spreading 4-bit symbol into IEEE 802.15.4-2003-defined 32-chip sequence. addition, provides interface software perform calibration module order reduce process, temperature, voltage variations.
6.2.2
TX_ACTIVE signal
Even though SN260 provides output power suitable most ZigBee applications, some applications will require external power amplifier (PA). timing requirements IEEE 802.15.4-2003, SN250 provides signal, TX_ACTIVE, used external power management Switching logic. When Baseband drives TX_ACTIVE high described inTable 15). When TX_ACTIVE signal low. external required, then TX_ACTIVE signal should connected through 100k resistor, shown application circuit Figure TX_ACTIVE signal only source current, based upon 1.8V signal swing. Control logic requires greater current voltage potential, then TX_ACTIVE should buffered externally SN260.
15/47
Functional description
SN260
Integrated module
SN260 integrates critical portions IEEE 802.15.4-2003 requirements hardware. This allows SN260 provide greater bandwidth application network operations. addition, hardware acts first-line filter non-intended packets. SN260 utilizes interface memory further reduce overall microcontroller interaction when transmitting receiving packets. When packet ready transmission, software configures indicating packet buffer location. waits backoff period, then transitions baseband mode performs channel assessment. When channel clear, reads data from buffer, calculates CRC, provides 4-bit symbols baseband. When final byte been read sent baseband, remainder read transmitted. resides mode most time, different format address filters keep non-intended packets from using excessive buffers, well preventing SN260 from being interrupted. When reception packet begins, reads 4-bit symbols from baseband calculates CRC. assembles received data storage buffer. provides direct access memory. Once packet been received, additional data appended packet buffer space. appended data provides statistical information packet software stack. primary features are:
generation, appending, checking Hardware timers interrupts achieve symbol timing Automatic preamble, pre-pended packet Address recognition packet filtering received packets Automatic acknowledgement transmission Automatic transmission packets from memory Automatic transmission after backoff time channel clear (CCA) Automatic acknowledgement checking Time stamping received transmitted messages Attaching packet information received packets (LQI, RSSI, gain, time stamp, packet status) IEEE 802.15.4-2003 timing slotted/unslotted timing
Packet trace interface (PTI)
SN260 integrates true PHY-level effective network-level debugging. This twosignal interface monitors packets non-intrusive manner) between baseband modules. asynchronous kbps interface cannot used inject packets into PHY/MAC interface. signals from SN260 frame signal (PTI_EN) data signal (PTI_DATA). supported InSight Desktop.
16/47
SN260
Functional description
16-bit microprocessor
SN260 integrates XAP2b microprocessor developed Cambridge Consultants Ltd., making true network processor solution. XAP2b 16-bit Harvard architecture processor with separate program data address spaces. word width bits both program data sides. standard XAP2 microprocessor accompanying software tools have been enhanced create XAP2b microprocessor used SN260. XAP2b adds data-side byte addressing support XAP2 allowing more productive usage optimized code. XAP2b clock speed 12MHz. When used with EmberZNet stack, firmware loaded into Flash memory using mechanism (described Section module programming debug interface) over serial link using built-in bootloader1 reserved area Flash. Alternatively, firmware loaded interface with assistance RAM-based utility routines also loaded SIF.
Embedded memory
SN260 contains embedded Flash memory firmware storage execution. addition partitions portion Flash simulated EEPROM token storage.
6.6.1
Simulated EEPROM
protocol stack reserves section Flash memory provide simulated EEPROM storage area stack customer tokens. Flash cell been qualified data retention time >100 years room temperature rated have guaranteed 1,000 write/erase cycles. Because Flash cells qualified 1,000 write cycles, simulated EEPROM implements effective wear-leveling algorithm which effectively extends number write cycles individual tokens. number set-token operations finite write cycle limitation Flash. possible guarantee exact number set-token operations because life simulated EEPROM depends which tokens written often. SN260 stores non-volatile information necessary network operation well tokens available Host. majority internal tokens only written when SN260 performs network join leave operation. simple estimate possible settoken operations, consider SN260 stable network joins leaves) sending messages where Host uses only 8-byte tokens available Under this scenario, very rough estimate results approximately 330,000 possible set-token operations. number possible set-token calls, though, depends which tokens being set, ratios set-token calls each token plays large factor. very rough estimate total number times token approximately 320,000. These estimates would typically increase SN260 kept closer room temperature, since 1,000 guaranteed write cycles Flash across temperature.
17/47
Functional description
SN260
6.6.2
Flash information area (FIA)
SN260 also includes separate 1024-byte that used storage data during manufacturing, including serial numbers calibration values. Programming this special Flash page only enabled using interface prevent accidental corruption erasure. EmberZNet stack reserves small portion this space addition makes eight manufacturing tokens available application.
Encryption accelerator
SN260 contains hardware encryption engine that attached using memory-mapped interface. CBC-MAC modes implemented hardware, CCM* implemented software. first modes described IEEE 802.15.4-2003 specification. CCM* described ZigBee Specification (ZigBee Document 053474). EmberZNet stack implements security applications that require security application level.
nRESET signal
When asynchronous external reset signal, nRESET (Pin 13), driven time greater than 200ns, SN260 resets default state. integrated glitch filter prevents noise from causing inadvertent reset occur. SN260 placed noisy environment, external Filter supervisory reset circuit recommended guarantee integrity reset signal. When nRESET asserts, SN260 registers return their reset state. addition, SN260 consumes 1.5mA (typical) current when held RESET.
Reset detection
SN260 contains multiple reset sources. reset event logged into reset source register, which lets determine cause last reset. following reset causes detected:
Power-on-reset Watchdog rollover Software reset Core power
18/47
SN260
Functional description
6.10
Power-on-reset (POR)
Each voltage domain (1.8V digital core supply VDD_CORE pads supply VDD_PADS) power-on-reset (POR) cell. VDD_PADS cell holds always-powered high-voltage domain reset until following conditions have been met:
high-voltage pads supply VDD_PADS voltage rises above threshold. internal clock starts generates three clock pulses. 1.8V cell holds main digital core reset until regulator output voltage rises above threshold.
Additionally, digital domain counts 1,024 clock edges 24MHz crystal before releasing reset main digital core. Table lists features SN260 circuitry. Table specifications
Parameter VDD_PADS release VDD_PADS assert 1.8V release 1.8V hysteresis Min. 1.00 0.50 1.35 0.08 Typ. 1.20 0.60 1.50 0.10 Max. 1.40 0.70 1.65 0.12 Unit
6.11
Clock sources
SN260 integrates oscillators: high-frequency 24-MHz crystal oscillator lowfrequency internal 10-kHz oscillator.
6.11.1
High-frequency crystal oscillator
integrated high-frequency crystal oscillator requires external 24MHz crystal with accuracy ±40ppm. Based upon application bill materials current consumption requirements, external crystal cover range requirements. lower ESR, cost crystal increases overall current consumption decreases. Likewise, higher ESR, cost decreases current consumption increases. Therefore, designer choose crystal needs application. Table lists specifications high-frequency crystal. Table High-frequency crystal specifications
Test conditions Min. Typ. Initial, temperature, aging Max. Unit dBc/Hz
Parameter Frequency Duty cycle Phase noise from Accuracy
19/47
Functional description Table High-frequency crystal specifications (continued)
Test conditions Load capacitance 10pF Load capacitance 18pF Min. Typ. Max. Good crystal: ESR, 10pF load Worst-case crystals (60, 18pF 100, 10pF) maximum bias
SN260
Parameter Crystal Crystal Start-up time stable clock (max. bias) Start-up time stable clock (optimum bias) Current consumption Current consumption Current consumption
Unit
6.11.2
Internal oscillator
SN260 low-power, low-frequency oscillator that runs time. nominal frequency kHz. oscillator coarse analog trim control, which first adjusted frequency close possible. This clock used chip management block. also divided down 1kHz using variable divider allow software accurately calibrate This calibrated clock used sleep timer. Timekeeping accuracy depends temperature fluctuations chip exposed power supply impedance, calibration interval, general will better than (including crystal error ppm). Table lists specifications oscillator. Table oscillator specifications
Parameter Frequency Analog trim steps Frequency variation with supply voltage drop from 3.6V 3.1V 2.6V 2.1V Test conditions Min. Typ. 0.75 Max. Unit
6.12
Random number generator
SN260 allows generation random numbers exposing randomly generated from ADC. Analog noise current passed through path, sampled receive ADC, stored register. value contained this register could used seed software-generated random number. EmberZNet stack utilizes these random numbers seed random backoff encryption generators.
20/47
SN260
Functional description
6.13
Watchdog timer
SN260 contains internal watchdog timer clocked from internal oscillator. timer reaches time-out value approximately seconds, will reset SN260. This reset signal cannot routed externally Host. SN260 firmware will periodically restart watchdog timer while firmware running normally. Host cannot effect configure watchdog timer.
6.14
Sleep timer
16-bit sleep timer contained always-powered digital block. clock source sleep timer calibrated 1kHz clock. frequency slowed down with prescaler generate final timer resolution 1ms. With tick 16-bit timer, timer wraps about every 65.5 seconds. EmberZNet stack appropriately handles timer wraps allowing Host order theoretical maximum sleep delay million seconds.
6.15
Power management
SN260 supports four different power modes: active, idle, deep sleep, power down. Active mode normal, operating state SN260. While idle mode, code execution halts until interrupt occurs. modules SN260 including radio continue operate normally. EmberZNet stack automatically invokes idle appropriate. Deep sleep mode power down mode both power most SN260, including radio, leave only critical chip functions powered. internal regulator disabled VREG_OUT turned off. output signals maintained frozen state. Upon waking from deep sleep power down mode, internal regulator re-enabled. Deep sleep power down result same sleep current consumption. sleep modes differ follows: SN260 wake both internal timer external signal from deep sleep mode; power down mode only wake external signal.
21/47
protocol
SN260
protocol
SN260 level protocol centers interface communication with pair GPIO handshake signaling.
SN260 looks like hardware peripheral. SN260 slave device transactions initiated Host (the master). SN260 supports reasonably high data rate.
Physical interface configuration
SN260 supports both Slave Mode (clock idle low, sample rising edge) Slave Mode (clock idle high, sample rising edge) maximum clock rate 5MHz, illustrated Figure
Note:
convention waveforms this document show Mode Figure transfer format, Mode Mode
nHOST_INT signal nWAKE signal both active low. Host must supply pull-up resistor nHOST_INT signal prevent errant interruptions during undefined events such SN260 resetting. SN260 supplies internal pull-up nWAKE signal prevent errant interruptions during undefined events such Host resetting.
transaction
basic SN260 transaction half-duplex ensure proper framing give SN260 adequate response time. basic transaction, shown Figure composed three sections: Command, Wait, Response. transaction considered analogous function call. Command section function call, Response section return value. Figure General timing diagram transaction
22/47
SN260
protocol
7.2.1
Command section
Host begins transaction asserting Slave Select then sending command SN260. This command length from bytes must begin with 0xFF. During Command section, SN260 will respond with only 0xFF. Host should ignore data MISO during Command section. Once Host completed transmission entire message, transaction moves Wait section.
7.2.2
Wait section
Wait section period time during which SN260 processing command performing other operations. Note that this section length time milliseconds. Because variable size Wait section, interrupt-driven polling-driven method suggested clocking opposed method. Since SN260 require milliseconds respond, long Host keeps Slave Select active, Host perform other tasks while waiting Response. determine when Response ready, methods:
Clock until SN260 transmits byte other than 0xFF. Interrupt falling edge nHOST_INT.
first method, clocking SPI, recommended simplicity implementing. During Wait section, SN260 will transmit only 0xFF will ignore incoming data until Response ready. When SN260 transmits byte other than 0xFF, transaction officially moved into Response section. Therefore, Host poll Response continuing clock transmitting 0xFF waiting SN260 transmit byte other than 0xFF. SN260 will also indicate that Response ready asserting nHOST_INT signal. falling edge nHOST_INT indication that Response ready. Once nHOST_INT signal asserts, nHOST_INT will return idle after Host begins clock data.
7.2.3
Response section
When SN260 transmits byte other than 0xFF, transaction officially moved into Response section. data format same format used Command section. response length from bytes will begin with 0xFF. Depending actual response, length response known from first second byte this length should used Host clock exactly correct number bytes. Once bytes have been clocked, allowable Host de-assert chip select. Since Host control clocking SPI, there ACKs similar signals needed back from Host because SN260 will assume Host could accept bytes being clocked SPI. After every transaction, Host must hold Slave Select high minimum 1ms. This timing requirement called inter-command spacing necessary allow SN260 process command become ready accept command.
7.2.4
Asynchronous signaling
When SN260 data send Host, will assert nHOST_INT signal. nHOST_INT signal designed edge-triggered signal opposed leveltriggered signal; therefore, falling edge nHOST_INT true indicator data availability. Host then responsibility initiate transaction SN260 output. Host should initiate this transaction soon possible prevent possible
23/47
protocol
SN260
backup data SN260. SN260 will de-assert nHOST_INT signal after receiving byte SPI. inherent latency SN260, timing when nHOST_INT signal returns idle vary between transactions. nHOST_INT will always return idle minimum 10µs before asserting again. SN260 more output available after transaction completed, nHOST_INT signal will assert again after Slave Select de-asserted Host must make another request.
7.2.5
Spacing
ensure that SN260 always able deal with incoming commands, minimum intercommand spacing defined 1ms. After every transaction, Host must hold Slave Select high minimum 1ms. Host must respect inter-command spacing requirement, SN260 will have time operate command; additional commands could result error conditions undesired behavior. nHOST_INT signal already asserted, Host allowed Wake handshake instead intercommand spacing determine SN260 ready accept command.
7.2.6
Waking SN260 from sleep
Waking SN260 involves simple handshaking routine illustrated Figure This handshaking ensures that Host will wait until SN260 fully awake ready accept commands from Host. SN260 already awake when handshake performed (such when Host resets SN260 already operating), handshake will proceed described below with effects.
Note:
wake handshake cannot performed nHOST_INT already asserted. Figure SN260 wake sequence
Waking SN260 involves following steps: Host asserts nWAKE. SN260 interrupts nWAKE exits sleep. SN260 performs operations needs will respond until ready accept commands. SN260 asserts nHOST_INT within 10ms nWAKE asserting. SN260 does assert nHOST_INT within 10ms nWAKE, valid Host consider SN260 unresponsive reset SN260. Host detects nHOST_INT assertion. Since assertion nHOST_INT indicates SN260 accept transactions, Host does need hold Slave Select high normally required minimum inter-command spacing. Host de-asserts nWAKE after detecting nHOST_INT assertion. SN260 will de-assert nHOST_INT within nWAKE de-asserting. After 25µs, change nHOST_INT will indication normal asynchronous (callback) event.
24/47
SN260
protocol
7.2.7
Error conditions
more different error conditions occur back back, only first error condition will reported Host possible report error). following error conditions that might occur with SN260.
Unsupported command Byte command unsupported, SN260 will drop incoming command respond with Unsupported Command Error Response. This error means Byte unsupported current Mode SN260 Bootloader Frames only used with bootloader EZSP Frames only used with EZSP.
Oversized Payload frame transaction includes Payload Frame, Length Byte cannot value greater than 133. SN260 detects length byte greater than 133, will drop incoming Command abort entire transaction. SN260 will then assert nHOST_INT after Slave Select returns Idle inform Host through error code Response section what happened. only Command problematic transaction dropped SN260, next Command also dropped, because responded with Oversized Payload Frame Error Response.
Aborted transaction aborted transaction transaction where Slave Select returns Idle prematurely Protocol dropped transaction. most common reason Slave Select returning Idle prematurely Host unexpectedly resetting. transaction aborted, SN260 will assert nHOST_INT inform Host through error code Response section what happened. When transaction aborted, only does Command problematic transaction dropped SN260, next Command also gets dropped since responded with Aborted Transaction Error Response.
Missing frame terminator Every Command Response must terminated with Frame Terminator byte. SN260 will drop Command that missing Frame Terminator. SN260 will then immediately provide Missing Frame Terminator Error Response.
Long transaction Long Transaction error occurs when Host clocks many bytes. long inter-command spacing requirement met, this error condition should cause problem, since SN260 will send only 0xFF outside Response section well ignore incoming bytes outside Command section.
Unresponsive Unresponsive mean SN260 powered, fully booted yet, incorrectly connected Host, busy performing other tasks. Host must wait maximum length Wait section before consider SN260 unresponsive Command section. This maximum length milliseconds, measured from last byte sent Command Section. SN260 ever fails respond during Wait section, valid Host consider SN260 unresponsive reset SN260. Additionally, nHOST_INT does assert within 10ms nWAKE asserting during wake handshake, Host consider SN260 unresponsive reset SN260.
25/47
protocol
SN260
protocol timing
Figure illustrates critical timing parameters Protocol. These timing parameters result SN260's internal operation both constrain Host behavior characterize SN260 operation. parameters shown discussed elsewhere this document. Note that Figure drawn scale, provided illustrate where parameters measured.
Figure
protocol timing waveform
Table lists timing parameters protocol. These parameters illustrated Figure Table
Parameter
protocol timing parameters
Description Wake handshake, while awake Wake handshake, while asleep Wake handshake finish Reset pulse width Startup time, entering application Startup time, entering bootloader nHOST_INT de-asserting after command Clock rate Wait section nHOST_INT de-asserting after response nHOST_INT asserting after transaction Inter-command spacing 200000 1500 Min. Typ. Max. Unit
Data format
data format, also referred command, same both Command section Response section. data format Protocol straightforward, illustrated Figure
26/47
SN260 Figure protocol data format
protocol
total length command must exceed bytes. commands must begin with Byte. Some commands only bytes-that they contain Byte Frame Terminator only. Length Byte only included there information Payload Frame Length Byte defines length just Payload Frame. Therefore, command includes Payload Frame, Length Byte have value from through overall command size will through bytes. Byte specific value indicating there Payload Frame not, there Payload Frame, then Length Byte expected. Error Byte used error responses provide additional information about error appears place length byte. This additional information described following sections. Payload Frame contains data needed operating EmberZNet. EZSP Frame format explained EZSP Reference Guide (120-3009-000). Payload Frame also contain data needed operating bootloader, which called Bootloader Frame. Refer EmberZNet Application Developer's Guide (120-4028-000) more information bootloader. Frame Terminator special control byte used mark command. Frame Terminator byte defined 0xA7 appended Commands Responses immediately after final data byte. purpose Frame Terminator provide known byte Protocol detect corrupt command. example, SN260 resets during Response Section, Host will still clock correct number bytes. when host attempts verify value 0xA7 Response, will either value 0x00 0xFF know that SN260 just reset corrupt Response should discarded. Note: Length Byte only specifies length Payload Frame. does include Frame Terminator.
byte
Table lists possible commands their responses Byte. Table
Command value
commands responses
Command Response value 0x00 0x01 Response SN260 reset occurred-This never used another response; always indicates SN260 Reset. Oversized Payload Frame received-This never used another response; always indicates overflow occurred. Aborted Transaction occurred-This never used another response; always indicates aborted transaction occurred.
0x02
27/47
protocol Table
Command value
SN260 commands responses (continued)
Command Response value 0x03 Response Missing Frame Terminator-This never used another response; always indicates missing frame terminator command. Unsupported Command-This never used another Response; always indicates unsupported Byte command. [none] bit[7] always set. bit[6] always cleared. bit[5:0] number from 1-63. bit[7] always set. bit[6] always set. bit[0]-Set Alive. [none] Bootloader frame EZSP frame Invalid
0x00 0x0F 0x0A
0x04
Reserved Protocol Version Status Reserved Bootloader Frame EZSP Frame Invalid
[none] 0x81 0xBF 0xC0 0xC1 [none] 0xFD 0xFE 0xFF
0x0B 0xF0 0xFC 0xFD 0xFE 0xFF
7.5.1
Primary bytes
There four primary bytes: protocol version, status, Bootloader frame EZSP frame.
protocol version [0x0A]: Sending this command requests Protocol Version number from Interface. response will always have cleared. this current version, response will 0x82, since version number corresponding this Command-Response values version number version number value from (0x81-0xBF). status [0x0B]: Sending this command asks SN260 status. response status byte will always have upper bits set. this current version, status byte only status [0], which SN260 alive ready commands. Bootloader frame [0xFD]: This byte indicates that current transaction Bootloader transaction there more data follow. This Byte will cause transaction look like full data format illustrated Figure byte immediately after this Byte will Length Byte, used identify length Bootloader Frame. Refer EmberZNet Application Developer's Guide (120-4028000) more information bootloader. Byte 0xFD, means minimum transaction size four bytes. EZSP frame [0xFE]: This byte indicates that current transaction EZSP transaction there more data follow. This Byte will cause transaction look like full data format illustrated Figure byte immediately after this Byte will Length Byte, used identify length EZSP Frame. (The EZSP Frame defined EZSP Reference Guide, 120-3009-000.) Byte 0xFE, means minimum transaction size five bytes
28/47
SN260
protocol
7.5.2
Special response bytes
There only five Byte values, 0x00-0x04, ever used error codes (see Table When error condition occurs, command sent SN260 will ignored responded with these codes. These special Bytes must trapped dealt with. addition, each error condition Error Byte (instead Length Byte) also sent with Byte.
Table
byte value 0x00
Byte values used error codes
Error message Error description Section 7.6: Powering power cycling, rebooting. command contained EZSP frame with Length Byte greater than 133. SN260 forced drop entire command. transaction completed properly SN260 forced abort transaction. Error byte description reset type. Refer documentation discussing EmberResetType. Reserved
SN260 Reset
0x01
Oversized EZSP Frame Aborted Transaction Missing Frame Terminator Unsupported Command
0x02
Reserved
0x03
command missing Frame Terminator. SN260 forced drop Reserved entire command. command contained unsup-ported Byte. SN260 forced drop entire Reserved command.
0x04
Powering power cycling, rebooting
When Host powers reboots), cannot guarantee that SN260 awake ready receive commands. Therefore, Host should always perform Wake SN260 handshake guarantee that SN260 awake. SN260 resets, needs inform Host that Host reconfigure stack needed. When SN260 resets, will assert nHOST_INT signal, telling Host that data. Host should request data from SN260 usual. SN260 will ignore whatever command sent respond only with bytes. first byte will always 0x00 second byte will reset type defined EmberResetType. This specialty Byte never used another Response Byte. Host sees 0x00 from SN260, knows that SN260 been reset. SN260 will de-assert nHOST_INT signal shortly after receiving byte process further commands usual manner. addition Host having control reset line SN260, EmberZNet Serial Protocol also provides mechanism software reboot.
7.6.1
Bootloading SN260
Protocol supports Payload Frame called Bootloader Frame communicating with SN260 when SN260 bootloader mode. SN260 enter bootload mode through either EZSP command holding pins while SN260 exits reset. Both nWAKE PTI_DATA capable activating bootloader while performing standard SN260 reset procedure. Assert nRESET hold
29/47
protocol
SN260
SN260 reset. While nRESET asserted, assert (active low) either nWAKE PTI_DATA then deassert nRESET boot SN260. deassert nWAKE PTI_DATA until SN260 asserts nHOST_INT, indicating that SN260 fully booted ready accept data over Protocol. Once nHOST_INT asserted, nWAKE PTI_DATA deasserted. Refer EmberZNet Application Developer's Guide (120-4028-000) more information bootloader format Bootloader Frame.
7.6.2
Unexpected resets
SN260 designed protect itself against undefined behavior unexpected resets. protection based state Slave Select since inter-command spacing mandates that Slave Select must return idle. SN260's internal Protocol uses Slave Select returning idle trigger re-initialize Protocol. always reinitializing, SN260 protected against Host unexpectedly resetting terminating transaction. Additionally, Slave Select active when SN260 powers SN260 will ignore data until Slave Select returns idle. ignoring traffic until idle, SN260 will begin receiving middle transaction. Host resets, most cases should reset SN260 well that both devices once again same state: freshly booted. Alternately, Host attempt recover from reset recovering previous state resynchronizing with state SN260. SN260 resets during transaction, Host expect either Wait Section timeout missing Frame Terminator indicating invalid Response. SN260 resets outside transaction, Host should proceed normally.
Transaction examples
This section contains following transaction examples:
protocol version EmberZNet serial protocol frame Version command SN260 reset Three-part transaction: Wake, Version, Stack Status Callback
7.7.1
protocol version
Figure protocol version example
30/47
SN260 Activate Slave Select (nSSEL). Transmit command 0x0A Protocol Version Request. Transmit Frame Terminator, 0xA7. Wait nHOST_INT assert. Transmit receive 0xFF until byte other than 0xFF received.
protocol
Receive response 0x82 byte other than 0xFF), then receive Frame Terminator, 0xA7. always always cleared Version Response, this Version De-activate Slave Select.
7.7.2
EmberZNet serial protocol frame Version command
Figure EmberZNet serial protocol frame Version command example
Activate Slave Select (nSSEL). Transmit appropriate command: 0xFE: Byte indicating EZSP Frame 0x04: Length Byte showing EZSP Frame bytes long 0x00: EZSP Sequence Byte (Note that this value should vary based upon previous sequence bytes) 0x00: EZSP Frame Control Byte indicating command with sleeping 0x00: EZSP Frame Byte indicating Version command 0x02: EZSP Parameter this command (desiredProtocolVersion) 0xA7: Frame Terminator
Wait nHOST_INT assert. Transmit receive 0xFF until byte other than 0xFF received. Receive response 0xFE byte other than 0xFF) read next byte length. Stop transmitting after number bytes (length) received plus Frame Terminator. Decode response: 0xFE: Byte indicating EZSP Frame 0x07: Length Byte showing EZSP Frame bytes long 0x00: EZSP Sequence Byte (Note that this value should vary based upon previous sequence bytes) 0x80: EZSP Frame Control Byte indicating response with overflow 0x00: EZSP Frame Byte indicating Version response 0x02: EZSP Parameter this response (protocolVersion) 0x02: EZSP Parameter this response (stackType)
31/47
protocol
SN260 0x11: EZSP Parameter this response (stackVersion). Note that this value vary). 0x30: EZSP Parameter this response (stackVersion). Note that this value vary). 0xA7: Frame Terminator
De-activate Slave Select.
7.7.3
SN260 reset
Figure SN260 reset example
nRESET toggles active reset SN260. nWAKE stays idle high between nRESET nHOST_INT indicating SN260 should continue with normal booting enter bootloader). nHOST_INT asserts. Activate Slave Select (nSSEL). Transmit command: 0xFE: Byte indicating EZSP Frame 0x03: Length Byte showing EZSP Frame bytes long 0x00: EZSP Sequence Byte (Note that this value should vary based upon previous sequence bytes) 0x00: EZSP Frame Control Byte indicating command with sleeping 0x06: EZSP Frame Byte indicating callback command 0xA7: Frame Terminator
Wait nHOST_INT assert. Transmit receive 0xFF until byte other than 0xFF received. Receive response 0x00 byte other than 0xFF). Receive Error Byte decode (0x02 enumerated RESET_POWERON).
Receive Frame Terminator (0xA7). Response 0x00 indicates SN260 reset Host should respond appropriately. Deactivate Slave Select. Since nHOST_INT does assert again, there more data Host.
32/47
SN260
protocol
7.7.4
Three-part transaction: Wake, Version, Stack Status Callback
Figure Timing diagram three-part transaction
Activate nWAKE activate timeout timer. SN260 wakes already) awake enables communication. nHOST_INT asserts, indicating SN260 accept commands. Host sees nHOST_INT activation within 10ms deactivates nWAKE timeout timer. nHOST_INT de-asserts immediately after nWAKE. Activate Slave Select. Transmit Command 0x0A Protocol Version Request. Transmit Frame Terminator, 0xA7. Wait nHOST_INT assert.
Transmit receive 0xFF until byte other than 0xFF received. Receive response 0x82 byte other than 0xFF), then receive Frame Terminator, 0xA7. always always cleared Version Response, this Version Deactivate Slave Select. Host begins timing inter-command spacing preparation sending next command. nHOST_INT asserts shortly after deactivating Slave Select, indicating callback. Host sees nHOST_INT, waits before responding. Activate Slave Select. Transmit command: 0xFE: Byte indicating EZSP Frame 0x03: Length Byte showing EZSP Frame bytes long 0x00: EZSP Sequence Byte (Note that this value should vary based upon previous sequence bytes) 0x00: EZSP Frame Control Byte indicating command with sleeping 0x06: EZSP Frame Byte indicating callback command 0xA7: Frame Terminator
Wait nHOST_INT assert. Transmit receive 0xFF until byte other than 0xFF received. Receive response 0xFE byte other than 0xFF), read next byte length. Stop transmitting after number bytes (length) received plus Frame Terminator.
33/47
protocol Decode response: 0xFE: Byte indicating EZSP Frame 0x04: Length Byte showing EZSP Frame bytes long
SN260
0x00: EZSP Sequence Byte (Note that this value should vary based upon previous sequence bytes) 0x80: EZSP Frame Control Byte indicating response with overflow 0x19: EZSP Frame Byte indicating stackStatusHandler command 0x91: EZSP Parameter this response (EmberStatus EMBER_NETWORK_DOWN) 0xA7 Frame Terminator
Deactivate Slave Select. Since nHOST_INT does assert again, there more data Host.
34/47
SN260
UART Gateway Protocol
UART Gateway Protocol
UART Gateway protocol designed network gateway systems which host processor running full-scale operating system such embedded Linux Windows. host sends EmberZNet Serial Protocol (EZSP) commands UART interface using Ember's Asynchronous Serial Host (ASH) protocol. EZSP commands same those used protocol, protocol better suited resource-constrained microcontroller hosts since uses considerably more host program storage. implements error detection/recovery tolerates latencies multi-tasking hosts scheduling buffering. protocol described detail UART Gateway Protocol Reference, 120-3010-000. Ember supplies host software source form compatible with Linux Windows. most cases will need only simple edits adapt particular host system. Figure UART interface signals
UART hardware interface uses following SN260 signals:
Serial data: protocol sends data both directions, both signals required. external pull-up resistor should connected avoid data glitches while SN260 resetting.
Flow control: nRTS nCTS (optional) uses hardware handshaking flow control: nRTS enables transmission from host SN260, nCTS enables SN260 transmissions host. host serial port cannot support RTS/CTS, XON/XOFF flow control used instead. But, XON/XOFF will deliver slightly lower performance. When using hardware flow control, SN260's nRTS must able control host serial output. However, many gateway systems, host will need throttle transmission SN260. those systems nCTS left unconnected since internal pull-down will continuously asserted.
Reset control: nRESET host must able reset SN260 protocol. best this host output connected nRESET. this feasible, host send special frame that requests SN260 reboot, this method less reliable than asserting nRESET recommended normal use.
35/47
UART Gateway Protocol UART signals follow usual conventions:
SN260
When idle, serial data high (marking) start (spacing), stop high (marking) Data bits sent least-significant first, with positive (non-inverting) logic flow control signals asserted
Note that commonly used transceivers invert these logic levels. Ember supplies UART Gateway protocol software versions: uses RTCS/CTS flow control other uses XON/XOFF. UART follows these versions:
115,200 RTS/CTS version 57,600 XON/XOFF version parity data bits stop
protocol been tuned optimal operation with configurations listed here. These configurations changed through manufacturing tokens, doing result degradation performance. learn change configuration, contact your local sales representative.
36/47
SN260
module programming debug interface
module programming debug interface
synchronous serial interface developed Cambridge Consultants Ltd. primary programming debug interface SN260. module allows external devices read write memory-mapped registers real-time without changing functionality timing XAP2b core. application note Design with SN260 (120-5047-000) PCB-level design details regarding implementation interface. SN260 pins involved Interface:
nSIF_LOAD SIF_CLK SIF_MOSI SIF_MISO nRESET
addition, VDD_PADS Ground required external voltage translation buffering Signals. interface provides following:
production test interface Virtual UART InSight Adapter Programming debug interface during EmberZNet Application Development
order achieve deep sleep currents specified Table pull-down resistor must connected SIF_MOSI pin. addition, Ember recommends pull-up resistor placed nSIF_LOAD order prevent noise from coupling onto signal. Both these recommendations documented within SN260 Reference designs. When developing application-specific manufacturing test procedures, Ember recommends designer refer Manufacturing Test Guidelines (120-5016-000). This document provides more detail regarding importance designing proper interface well timing SIF.
37/47
Typical application
SN260
Typical application
Figure illustrates typical application circuit SN260 using Protocol. This figure does contain decoupling capacitance required SN260. Balun provides impedance transformation from antenna SN260 both modes. harmonic filter provides additional suppression second harmonic, which increases margin over limit. 24MHz crystal with loading capacitors required provides high frequency source SN260. debounce filter suggested improve noise immunity nRESET logic (Pin 11). (nSIF_LOAD, SIF_MOSI, SIF_MISO, SIF_CLK), Packet Trace (PTI_EN PTI_DATA), SDBG signals should brought test points space permits 10pin, dual row, 0.05-inch pitch header footprint. With header populated, direct connection InSight Adapter possible which enhances debug capability SN260. more information, visit www.st.com/mcu.
Figure Typical application circuit protocol
SN260
Table contains bill materials application circuit shown Figure
38/47
SN260 Table Bill materials
Reference C1,C3 C4,C5 BLN1 Description Capacitor, 5pF, 50V, NPO, 0402 Capacitor, 0.5pF, 50V, NPO, 0402 Capacitor, 27pF, 50V, NPO, 0402 Capacitor, 10µF, 10V, TANTALUM, 3216 (SIZE Capacitor, 10pF, NPO, 0402 Inductor, 2.7nH, 0603, multi-layer Inductor, 3.3nH, 0603, multi-layer Resistor, 0402 Resistor, O402 Resistor, 0402 Resistor, 0402 SN260 single-chip ZigBee/802.15.4 solution Crystal, 24.000MHz, tolerance, stability, 18pF, 40°C 85°C BALUN, ceramic
Typical application
Item Quantity
Manufacturer/Part
MURATA LQG18HN2N7 MURATA LQG18HN3N3
STMicroelectronics SN260 ILSI ILCX08-JG5F18-24.000MHZ HHM1521
39/47
Package mechanical data
SN260
Package mechanical data
SN260 package plastic 40-pin that 0.9mm. Figure illustrates package drawing.
Figure Package drawing
Ordering information
following part numbers order SN260:
SN260QT Reel, RoHS SN260Q Tray, RoHS
order parts, contact your local STMicroelectronics sales representative, site: www.st.com.
40/47
SN260
Electrical characteristics
13.1
Table
Electrical characteristics
Absolute maximum ratings
Table lists absolute maximum ratings SN260. Absolute maximum ratings
Parameter Test conditions Min. Max. Unit
Regulator voltage (VDD_PADS) Core voltage (VDD_24MHZ, VDD_VCO, VDD_RF, VDD_IF, VDD_PADSA, VDD_FLASH, VDD_SYNTH_PRE, VDD_CORE) Voltage RF_P,N; RF_TX_ALT_P,N input power (For max. level correct packet reception, Table Voltage 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 TX_ACTIVE, BIAS_R, OSCA, OSCB Storage temperature
VDD_PADS+0.3
VDD_CORE+0.3
13.2
Table
Recommended operating conditions
Table lists rated operating conditions SN260. Operating conditions
Parameter Test conditions Min. Typ. Max. Unit
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
41/47
Electrical characteristics
SN260
13.3
Table
Environmental characteristics
Table lists environmental characteristics SN260. Environmental characteristics
Parameter Test Conditions Non-RF pins pins Min. MSL3 Typ. Max. Unit
(human body model) (charged device model) (charged device model) (moisture sensitivity level)
13.4
Table
electrical characteristics
Table lists electrical characteristics SN260. characteristics
Parameter Test Conditions Min. Regulator output external input Typ. Max. Unit
Regulator input voltage (VDD_PADS) Power supply range (VDD_CORE) Deep sleep current Quiescent current, including internal oscillator RESET current Quiescent current, nRESET asserted current Radio receiver, MAC, baseband (boost mode) Radio receiver, MAC, baseband CPU, Flash memory Total current IRadio receiver, baseband, IRAM, Flash memory current Radio transmitter, MAC, baseband (boost mode) Radio transmitter, MAC, baseband CPU, RAM, Flash memory max. power 5dBm typical) max. power 3dBm typical) 0dBm typical min. power 32dBm typical) VDD_PADS 3.0V Total current IRadio transmitter, 1.8V core; max. power baseband, IRAM, Flash memory 1.8V core VDD_PADS 3.0V C/3V C/3.6V
30.0 28.0 36.0
34.0 28.0 24.0 19.0 36.0
42/47
SN260
Electrical characteristics
13.5
Digital specifications
Table contains digital specifications SN260. digital power (named VDD_PADS) comes from three dedicated pins (pins 24). voltage applied these pins sets voltage.
Table
Digital specifications
Parameter Name VDD_PADS RIPU RIPD IOHS IOLS IOHH IOLH VDD_CORE 0.18 VDD_CORE 0.82 VDD_PADS 0.18 VDD_PADS VDD_PADS VDD_PADS 0.82 VDD_CORE Min. VDD_PADS Typ. Max. VDD_PADS VDD_PADS -0.5 Unit
Voltage supply Input voltage logic Input voltage logic Input current logic Input current logic Input pull-up resistor value Input pull-down resistor value Output voltage logic Output voltage logic Output source current (standard current pad) Output sink current (standard current pad) Output source current (high current pad: pins Output sink current (high current pad: pins Total output current (for pads) Input voltage threshold OSCA Output voltage level (TX_ACTIVE) Output source current (TX_ACTIVE)
43/47
Electrical characteristics
SN260
13.6
13.6.1
Note:
electrical characteristics
Receive
Table lists parameters integrated IEEE 802.15.4 receiver SN260. Receive measurements were collected with Ember's SN260 Lattice Balun Reference Design 2440 using EmberZNet software stack Version 3.0.1. Typical number indicates standard deviation above mean, measured room temperature (25° numbers measured over process corners room temperature (25° Receive characteristics
Parameter Test conditions Min. 2400 PER, 20byte packet defined IEEE 802.15.4 PER, 20byte packet defined IEEE 802.15.4 IEEE 802.15.4 signal -82dBm IEEE 802.15.4 signal 82dBm IEEE 802.15.4 signal 82dBm IEEE 802.15.4 signal 82dBm IEEE 802.15.4 signal 82dBm -100 IEEE 802.15.4 signal 82dBm Typ. Max. 2500 Unit
Table
Frequency range Sensitivity (boost mode) Sensitivity High-side adjacent channel rejection Low-side adjacent channel rejection high-side adjacent channel rejection
low-side adjacent channel rejection Channel rejection other channels
802.11g rejection centered 12MHz IEEE 802.15.4 signal 82dBm 13MHz Maximum input signal level correct operation (low gain) Image suppression Co-channel rejection Relative frequency error required IEEE 802.15.4) Relative timing error required IEEE 802.15.4) Linear RSSI range RSSI range
44/47
SN260
Electrical characteristics
13.6.2
Note:
Transmit
Table lists parameters integrated IEEE 802.15.4 transmitter SN260. Transmit measurements were collected with Ember's SN260 Lattice Balun Reference Design 2440 using EmberZNet software stack Version 3.0.1. Typical number indicates standard deviation above mean, measured room temperature (25° numbers measured over process corners room temperature (25° Transmit characteristics
Parameter Test conditions highest power setting highest power setting lowest power setting defined IEEE 802.15.4, which sets maximum away away -0.5 Min. Typ. Max. Unit
Table
Maximum output power (boost mode) Maximum output power Minimum output power Error vector magnitude Carrier frequency error Load impedance mask relative mask absolute
13.6.3
Synthesizer
Table lists parameters integrated synthesizer SN260.
Table
Parameter
Synthesizer characteristics
Test conditions Min. 2400 11.7 From off, with correct setting Channel change RX/TX turnaround (IEEE 802.15.4 defines 192s turnaround time) -103 -111 Typ. Max. 2500 Unit dBc/Hz dBc/Hz dBc/Hz dBc/Hz
Frequency range Frequency resolution Lock time Relock time Phase noise Phase noise Phase noise Phase noise
45/47
Revision history
SN260
Revision history
Table
Date 11-Dec-2006 03-Dec-2007 17-Apr-2008 23-Mar-2009
Document revision history
Revision Initial release. Document status promoted from Preliminary Data Datasheet. Corrected units value Figure protocol timing parameters page Added UART Gateway Protocol section. Removed EmberZNet serial protocol section. Changes
46/47
SN260
Please Read Carefully:
Information this document provided solely connection with products. STMicroelectronics subsidiaries ("ST") reserve right make changes, corrections, modifications improvements, this document, products services described herein time, without notice. products sold pursuant ST's terms conditions sale. Purchasers solely responsible choice, selection products services described herein, assumes liability whatsoever relating choice, selection products services described herein. license, express implied, estoppel otherwise, intellectual property rights granted under this document. part this document refers third party products services shall deemed license grant such third party products services, intellectual property contained therein considered warranty covering manner whatsoever such third party products services intellectual property contained therein.
UNLESS OTHERWISE FORTH ST'S TERMS CONDITIONS SALE DISCLAIMS EXPRESS IMPLIED WARRANTY WITH RESPECT AND/OR SALE PRODUCTS INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES MERCHANTABILITY, FITNESS PARTICULAR PURPOSE (AND THEIR EQUIVALENTS UNDER LAWS JURISDICTION), INFRINGEMENT PATENT, COPYRIGHT OTHER INTELLECTUAL PROPERTY RIGHT. UNLESS EXPRESSLY APPROVED WRITING AUTHORIZED REPRESENTATIVE, PRODUCTS RECOMMENDED, AUTHORIZED WARRANTED MILITARY, CRAFT, SPACE, LIFE SAVING, LIFE SUSTAINING APPLICATIONS, PRODUCTS SYSTEMS WHERE FAILURE MALFUNCTION RESULT PERSONAL INJURY, DEATH, SEVERE PROPERTY ENVIRONMENTAL DAMAGE. PRODUCTS WHICH SPECIFIED "AUTOMOTIVE GRADE" ONLY USED AUTOMOTIVE APPLICATIONS USER'S RISK.
Resale products with provisions different from statements and/or technical features forth this document shall immediately void warranty granted product service described herein shall create extend manner whatsoever, liability
logo trademarks registered trademarks various countries. Information this document supersedes replaces information previously supplied. logo registered trademark STMicroelectronics. other names property their respective owners.
2009 STMicroelectronics rights reserved STMicroelectronics group companies Australia Belgium Brazil Canada China Czech Republic Finland France Germany Hong Kong India Israel Italy Japan Malaysia Malta Morocco Singapore Spain Sweden Switzerland United Kingdom United States America www.st.com
47/47

ZigBee® 802.15.4 network processor Integrated 2.4GHz, IEEE 802.15

Top Searches for this datasheet

Other recent searches