Transaction Examples#

This section contains the following transaction examples:

• SPI Protocol Version

• EmberZNet Serial Protocol Frame—Version Command

• NCP Reset

• EZSP-SPI status

• Three-Part Transaction: Wake, Get Version, Stack Status Callback

Note: The specific bytes of the EZSP portion of the frame examples below may vary among stack releases and especially among EZSP protocol versions. To confirm the EZSP frame format expected by your NCP firmware, please refer to the "Protocol Format" section of UG100: EZSP Reference Guide from the specific EmberZNet release corresponding to your NCP’s firmware build.

NCP Reset#

Note: The following steps begin by resetting the NCP to guarantee that it is in a known state. The NCP resetting is an error and results in the first transaction performed after a reset returning the reset error. These steps describe receiving this reset error instead of the EZSP-SPI Protocol Version. The EZSP-SPI protocol version transaction is described in SPI Protocol Version.

1. Assert nRESET and release, which toggles active low to reset the NCP and guarantee it is in a known status..

2. nWAKE stays idle high between nRESET and nHOST_INT indicating the NCP should continue with normal booting (do not enter the bootloader).

3. nHOST_INT asserts, indicating that the NCP is active.

4. Assert nSSEL to begin a transaction.

5. Transmit the command:

   • 0xFE: SPI Byte indicating an EZSP Frame

   • 0x05: Length Byte showing the EZSP Frame is 5 bytes long

   • 0x00: EZSP Sequence Byte (Note that this value should vary based upon previous sequence bytes)

   • 0x00: EZSP Frame Control Low Byte indicating a command with no sleeping

   • 0x01: EZSP Frame Control High Byte indicating the frame version is 1 and not using an encrypted EZSP connection

   • 0x0600: EZSP Frame ID (2 bytes) indicating the callback command (sending the low byte first, so the EZSP Frame ID is 0x0006)

   • 0xA7: Frame Terminator

6. Wait for nHOST_INT to assert.

7. Transmit and receive 0xFF until a byte other than 0xFF is received.

8. Receive response 0x00 (a byte other than 0xFF).

9. Receive the Error Byte and decode (0x02 is enumerated as RESET_POWERON).

10. Receive the Frame Terminator (0xA7).

11. Response 0x00 indicates the NCP has reset and the Host should respond appropriately.

12. Deassert nSSEL to finish the transaction.

13. Since nHOST_INT does not assert again, there is no more data for the Host.

EZSP-SPI Status#

The EZSP-SPI Status transaction is very similar to the EZSP-SPI Protocol Version transaction. Like the EZSP-SPI Protocol Version transaction, this transaction provides a simple example of interaction with the NCP. Silicon Labs recommends this as a test transaction to verify the connection with the NCP during the host’s boot sequence.

1. Assert nSSEL to begin a transaction.

2. Transmit 0x0B.

3. Transmit 0xA7.

4. Continually transmit 0xFF until the byte received is not 0xFF. The first byte received that is not 0xFF will be 0xC1.

5. Transmit 0xFF while receiving 0xA7.

6. Deassert nSSEL to finish the transaction.

SPI Protocol Version#

Obtaining the EZSP-SPI Protocol Version is a compact, simplified, and special transaction that illustrates a full transaction. Being able to properly obtain the EZSP-SPI Protocol Version not only verifies five of the seven interface pins (MOSI, MISO, SCLK, nSSEL, and nHOST_INT), but it is also useful as a test for verifying that the NCP is active and that the EZSP-SPI Protocol code being implemented on the host is compatible with the firmware on the NCP. Use this transaction to verify the connection with the NCP during the host’s boot sequence.

1. Activate Slave Select (nSSEL).

2. Transmit the command 0x0A - SPI Protocol Version Request.

3. Transmit the Frame Terminator, 0xA7.

4. Wait for nHOST_INT to assert.

5. Transmit and receive 0xFF until a byte other than 0xFF is received.

6. Receive response 0x82 (a byte other than 0xFF), then receive the Frame Terminator, 0xA7.

7. Bit 7 is always set and bit 6 is always cleared in the Version Response, so this is Version 2.

8. Deactivate Slave Select.

EmberZNet Serial Protocol Frame—Version Command#

Before implementing a generic EZSP-SPI Protocol on the host, Silicon Labs recommends explicitly coding a transaction for providing exposure to an EZSP Frame and the format of the data involved with an EZSP Frame. The EZSP Frame used in this transaction is the VERSION command. The VERSION command must be the first EZSP command issued to the NCP. It exercises the code path all the way through the NCP firmware. Therefore, this command is useful not only for verifying that the EZSP is active, but also for illustrating the implementation of an EZSP transaction.

1. Assert nSSEL to begin a transaction.

2. Transmit the appropriate command:

   • 0xFE: SPI Byte indicating an EZSP Frame

   • 0x06: Length Byte showing the EZSP Frame is 6 bytes long

   • 0x00: EZSP Sequence Byte (Note that this value should vary based upon previous sequence bytes)

   • 0x00: EZSP Frame Control Low Byte indicating a command with no sleeping

   • 0x01: EZSP Frame Control High Byte indicating the frame version is 1 and not using an encrypted EZSP connection

   • 0x0000: EZSP Frame ID (2 bytes) indicating the Version command

   • 0x08: EZSP Parameter for this command (desiredProtocolVersion, note that this value may vary; your software may be newer than the version 8 shown here).

   • 0xA7: Frame Terminator

3. Wait for nHOST_INT to assert.

4. Transmit and receive 0xFF until a byte other than 0xFF is received.

5. Receive response 0xFE (a byte other than 0xFF) and read the next byte for a length.

6. Stop transmitting after the number of bytes (length) is received plus the Frame Terminator.

7. Decode the response:

   • 0xFE: SPI Byte indicating an EZSP Frame

   • 0x09: Length Byte showing the EZSP Frame is 9 bytes long

   • 0x00: EZSP Sequence Byte (Note that this value should vary based upon previous sequence bytes)

   • 0x80: EZSP Frame Control Low Byte indicating a response with no errors and with no pending callbacks

   • 0x01: EZSP Frame Control High Byte indicating the frame version is 1 and not using an encrypted EZSP connection

   • 0x0000: EZSP Frame ID (2 bytes) indicating the Version response

   • 0x08: EZSP Parameter for this response (protocolVersion, note that this value may vary; your software may be newer than the version 8 shown here)

   • 0x02: EZSP Parameter for this response (stackType)

   • 0x00: EZSP Parameter for this response (stackVersion, note that this value may vary)

   • 0x67: EZSP Parameter for this response (stackVersion: denotes the major version and minor version, such as 0x67 for EmberZNet 6.7).)

   • 0xA7: Frame Terminator

8. Deassert nSSEL to finish the transaction.

Three-Part Transaction: Wake, Get Version, Stack Status Callback#

1. Activate nWAKE and activate timeout timer.

2. NCP wakes up (if not already) and enables communication.

3. nHOST_INT asserts, indicating the NCP can accept commands.

4. Host sees nHOST_INT activation within 300 ms and deactivates nWAKE and timeout timer.

5. nHOST_INT deasserts immediately after nWAKE.

6. Assert nSSEL to begin a transaction.

7. Transmit the Command 0x0A - SPI Protocol Version Request.

8. Transmit the Frame Terminator, 0xA7.

9. Wait for nHOST_INT to assert.

10. Transmit and receive 0xFF until a byte other than 0xFF is received.

11. Receive response 0x82 (a byte other than 0xFF), then receive the Frame Terminator, 0xA7.

12. Bit 7 is always set and bit 6 is always cleared in the Version Response, so this is Version 2.

13. Deassert nSSEL to finish the transaction.

14. Host begins timing the inter-command spacing of 1 ms in preparation for sending the next command.

15. nHOST_INT asserts shortly after deactivating Slave Select, indicating a callback.

16. Host sees nHOST_INT, but waits for the 1 ms before responding.

17. Assert nSSEL to begin a transaction.

18. Transmit the command:

    • 0xFE: SPI Byte indicating an EZSP Frame

    • 0x05: Length Byte showing the EZSP Frame is 5 bytes long

    • 0x00: EZSP Sequence Byte (Note that this value should vary based upon previous sequence bytes)

    • 0x00: EZSP Frame Control Low Byte indicating a command with no sleeping

    • 0x01: EZSP Frame Control High Byte indicating the frame version is 1 and not using an encrypted EZSP connection

    • 0x0600: EZSP Frame ID (2 bytes) indicating the callback command (sending the low byte first, so the EZSP Frame ID is 0x0006)

    • 0xA7: Frame Terminator

19. Wait for nHOST_INT to assert.

20. Transmit and receive 0xFF until a byte other than 0xFF is received.

21. Receive response 0xFE (a byte other than 0xFF), read the next byte for a length.

22. Stop transmitting after the number of bytes (length) is received plus the Frame Terminator.

23. Decode the response:

    • 0xFE: SPI Byte indicating an EZSP Frame

    • 0x06: Length Byte showing the EZSP Frame is 6 bytes long

    • 0x00: EZSP Sequence Byte (Note that this value should vary based upon previous sequence bytes)

    • 0x80: EZSP Frame Control Low Byte indicating a response with no errors

    • 0x01: EZSP Frame Control High Byte indicating the frame version is 1 and not using an encrypted EZSP connection

    • 0x1900: EZSP Frame ID (2 bytes) indicating the stackStatusHandler command (sending the low byte first, so the EZSP Frame ID is 0x0019)

    • 0x91: EZSP Parameter for this response (EmberStatus EMBER_NETWORK_DOWN)

    • 0xA7: Frame Terminator

24. Deassert nSSEL to finish the transaction

25. Since nHOST_INT does not assert again, there is no more data for the Host.