EM260-RTR datasheet(29/50 Pages) SILICONIMAGE

29 / 50 page

EM260

Page 29

120-0260-000M Rev 1.1

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

mechanism for a software reboot.

5.6.1

Bootloading the EM260

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 document UG103.6, Ember Application

Development Fundamentals: Bootloading, for more information on the bootloader and the format of the

Bootloader Frame.

5.6.2

Unexpected Resets

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.

5.7

Transaction Examples

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

EM260-RTR 数据表(PDF) 29 Page - Silicon image

EM260-RTR 数据表(HTML) 29 Page - Silicon image

Html Pages

1 2 3 4 5 6 7 8 9 10 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 42 43 44 45 46 47 48 49 50

数据表下载