Powering On, Power Cycling, and Rebooting#

When the Host powers on (or reboots), it cannot guarantee that the NCP is awake and ready to receive commands. Therefore, the Host should always perform the Wake NCP handshake to guarantee that the NCP is awake. If the NCP resets, it needs to inform the Host so that the Host can reconfigure the stack if needed.

When the NCP resets, it will assert the nHOST_INT signal, telling the Host that it has data. The Host should request data from the NCP as usual. The NCP 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 platform/service/legacy_hal/inc/em2xx-reset-defs.h. This specialty SPI Byte is never used in another Response SPI Byte. If the Host sees 0x00 from the NCP, it knows that the NCP has been reset. The NCP 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 NCP, the EmberZNet Serial Protocol also provides a mechanism for a software reboot.

When the host resets, it is far simpler to reset the NCP and begin from a known state than to try to recover and resync with the previous (unknown) state of the NCP. The recommended procedure when the host resets is to perform a Hard Reset of the NCP during bootup. A Hard Reset is defined as the following sequence:

  1. Toggle nRESET (active low) to reset the NCP.

  2. Wait for nHOST_INT to assert, which indicates that the NCP is active.

  3. Perform an EZSP-SPI Protocol Version transaction and verify that the Response from the NCP is the NCP Reset error condition.

  4. Perform an EZSP-SPI Protocol Version transaction and verify that the EZSP-SPI Protocol Version number is as expected.

  5. Perform an EZSP-SPI Status transaction and verify that the NCP is "Alive" and ready to accept commands.

The purpose of performing this Hard Reset on bootup is threefold.

  • By guaranteeing that the NCP is freshly booted, just like the host, the host can proceed with standard node and network initialization instead of consuming extra code space just trying to determine what state the NCP was left in.

  • Because the NCP generates the NCP Reset error, which will override any legitimate transaction Response, the Hard Reset can acknowledge this planned and expected error condition so that the EZSP or full application does not have to implement special handling. Therefore, whenever an NCP Reset error is experienced outside of a Hard Reset, it can be treated as a true unexpected error condition.

  • The EZSP-SPI Protocol Version and EZSP-SPI Status transactions are specialized transactions not implemented or used by the normal EZSP. These transactions are intended to be utility devices that allow the host to perform a simple "handshake" with the NCP. This handshake not only verifies that the NCP is alive and available to the EZSP, but also that the EZSP-SPI Protocol implemented in the NCP is compatible with the EZSP-SPI Protocol implemented on the host.