EM260-RTY Ember, EM260-RTY Datasheet - Page 29

• Manufacturer Part Number: EM260-RTY
• Description: IC ZIGBEE SYSTEM-ON-CHIP 40-QFN
• Manufacturer: Ember

Specifications of EM260-RTY

• Frequency: 2.4GHz
• Data Rate - Maximum: 250kbps
• Modulation Or Protocol: 802.15.4
• Applications: ZigBee™
• Power - Output: -32dBm ~ 3dBm
• Sensitivity: -97dBm
• Voltage - Supply: 2.1 V ~ 3.6 V
• Current - Receiving: 30mA
• Current - Transmitting: 34mA
• Data Interface: PCB, Surface Mount
• Antenna Connector: PCB, Surface Mount
• Operating Temperature: -40°C ~ 85°C
• Package / Case: 40-QFN
• Lead Free Status / RoHS Status: Lead free / RoHS Compliant
• Memory Size: -
• Other names: 636-1003

5.6
SPI Byte Value Error Message
[0x00]
[0x01]
[0x02]
[0x03]
[0x04]
Powering On, Power Cycling, and Rebooting
EM260 Reset
Oversized EZSP
Frame
Aborted Transaction The transaction was not completed properly
Missing Frame
Terminator
Reserved
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.
When the Host powers on (or reboots), it cannot guarantee that the EM260 is awake and ready to receive
commands. Therefore, the Host should always perform the Wake EM260 handshake to guarantee that the
EM260 is awake. If the EM260 resets, it needs to inform the Host so that the Host can reconfigure the stack if
needed.
When the EM260 resets, it will assert the nHOST_INT signal, telling the Host that it has data. The Host should
request data from the EM260 as usual. The EM260 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 EM260, it knows that the EM260 has been reset. The EM260 will deassert 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 EM260, the EmberZNet Serial Protocol also provides a mecha-
nism for a software reboot.
5.6.1
The EM260 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 EM260’s internal SPI Protocol uses Slave Select returning to idle as a trigger to reinitialize its SPI
Protocol. By always reinitializing, the EM260 is protected against the Host unexpectedly resetting or terminat-
ing a transaction. Additionally, if Slave Select is active when the EM260 powers on, the EM260 will ignore SPI
data until Slave Select returns to idle. By ignoring SPI traffic until idle, the EM260 will not begin receiving in
the middle of a transaction.
If the Host resets, in most cases it should reset the EM260 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 EM260.
If the EM260 resets during a transaction, the Host can expect either a Wait Section timeout or a missing Frame
Terminator indicating an invalid Response.
If the EM260 resets outside of a transaction, the Host should proceed normally.
Unexpected Resets
Error Description
See section 5.6, Powering On, Power Cycling,
and Rebooting.
The command contained an EZSP frame with a
Length Byte greater than 125. The EM260 was
forced to drop the entire command.
and the EM260 was forced to abort the trans-
action.
The command was missing the Frame Termina-
tor. The EM260 was forced to drop the entire
command.
[none]
Table 17. Byte Values Used as Error Codes
[none]
Error Byte Description
The reset type. Refer to Ember’s API
documentation discussing
EmberResetType.
Reserved
Reserved
Reserved
120-1003-000D
EM260
29