SN260 datasheet(29/88 Pages) STMICROELECTRONICS

29 / 88 page

SN260

SPI protocol

29/88

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 re-

initializing, 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-part transaction: Wake, Get Version, Stack Status Callback

SN260 bảng dữ liệu(PDF) 29 Page - STMicroelectronics

SN260 bảng dữ liệu(HTML) 29 Page - STMicroelectronics

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 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88

bảng dữ liệu tải về

Link URL