SN260 View Datasheet(PDF) - STMicroelectronics
Part Name
Description
MFG CO.
'SN260' PDF : 88 Pages View PDF
SN260
6.6
6.6.1
SPI protocol
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.
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
29/88
Share Link: 
