EM260-RCM-USART-R Ember, EM260-RCM-USART-R Datasheet - Page 29

• Manufacturer Part Number: EM260-RCM-USART-R
• Description: EM260 RCM BOARD
• Manufacturer: Ember
• Type: Transceiver, 802.15.4/ZigBeer

Specifications of EM260-RCM-USART-R

• Frequency: 2.4GHz
• For Use With/related Products: EM260
• Lead Free Status / RoHS Status: Lead free / RoHS Compliant
• Other names: 636-1025

5.7
Transaction Examples
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
EmberResetType
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
mechanism for a software reboot.
5.6.1
The SPI Protocol supports a Payload Frame called the Bootloader Frame for communicating with the EM260
when the EM260 is in bootloader mode. The EM260 can enter bootload mode through either an EZSP command
or holding one of two pins low while the EM260 exits reset. Both the nWAKE pin and the PTI_DATA pin are
capable of activating the bootloader while performing a standard EM260 reset procedure. Assert nRESET to
hold the EM260 in reset. While nRESET is asserted, assert (active low) either nWAKE or PTI_DATA and then
deassert nRESET to boot the EM260. Do not deassert nWAKE or PTI_DATA until the EM260 asserts nHOST_INT,
indicating that the EM260 has fully booted and is ready to accept data over the SPI Protocol. Once nHOST_INT
is asserted, nWAKE or PTI_DATA way be deasserted. Refer to the EmberZNet Application Developer’s Guide
(120-4028-000) for more information on the bootloader and the format of the Bootloader Frame.
5.6.2
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
terminating 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.
This section contains the following transaction examples:
•
•
•
•
SPI Protocol Version
EmberZNet Serial Protocol Frame-Version Command
EM260 Reset
Three-Part Transaction: Wake, Get Version, Stack Status Callback
Bootloading the EM260
Unexpected Resets
. This specialty SPI Byte is never used in another Response SPI Byte. If the Host sees
Page 29
0x00
and the second byte will be the reset type as defined by
EM260
120-0260-000J
0x00