Which EM260 firmware image should I load? What are the feature differences between these?

With Ember’s EM260 images, the filenames usually reflect the EZSP serial style used. Depending on the release of EmberZNet you’re using, the firmware filenames may differ according to the significant pieces of functionality that are present/missing from the EM260 network coprocessor [NCP] images.

So, for example, in EmberZNet 3.3.0, there is only one SPI EZSP firmware image: em260-spi-with-standalone-bootloader.hex . This supports all features mentioned below, including debug capability and radio+SPI bootloader support.

However, in the EmberZNet 3.2.0 EM260 release, there are the following SPI NCP HEX files for EM260:

1. em260-spi-with-bootloader-no-debug-no-alarms-no-link-keys.hex
2. em260-spi-with-bootloader-no-debug-no-end-dev-bind.hex
3. em260-spi-with-debug-no-bootloader.hex

The first contains Standalone Bootloader capability (for update via SPI or OTA) but removes the ability to get EZSP traces in the capture stream of ISD (only packet tracing and critical events are reported). It also omits support for the EmberZNet Alarm mechanism, which is used by sleepy (or mobile) end devices and their parents to allow important messages (alarms, either broadcast or unicast) to be held by the parent indefinitely rather than being subject to the Indirect Transmission Timeout. (See http://portal.ember.com/node/636 for more details on using Alarms.) The third piece that is omitted is full support for unique APS link keys, meaning that only global link keys or hashed (pseudo-unique) link keys can be used; nodes such as the Trust Center cannot maintain truly unique (non-hashed) APS link keys for multiple devices. This means that if the application wishes to use APS encryption between a pair of nodes in the network, it must either use a global link key (which would be the same as used for Trust Center communication) for this or would need to use a link key hashed (via the HMAC algorithm) from the EUI64 of the other node. All other stack features are supported.

The second image contains full Standalone Bootloader capability also, but omits End Device Bind support, which is used at the coordinator (and only the coordinator) to facilitate handling ZDO End Device Bind Requests from nodes. This feature is used to pair up nodes with related capabilities by having the coordinator match up two requests with corresponding client and server clusters if the requests arrive within a given timeframe. Other than this feature, all other stack features are present, so non-coordinator devices don’t lose anything by utilizing this image.

The third images contains all features (including unique link key support, end device bind handling support for coordinators, EZSP debug tracing, and Alarm support) of the stack, but does not include the Standalone Bootloader, so the node can send bootloader packets OTA to other target nodes but the EM260 itself can’t be updated through any mechanism other than the SIF programming interface (chip programmer hardware like UBSLink or InSight Adapter).

With the EZSP-UART NCP firmware, all stack features can fit into the image, along with support for a serial-only bootloader that allows EM260 updates via UART (no OTA target support). The only decision to be made concerns the protocol implementation itself:

• em260-uart-rts-cts-with-bootloader.hex contains full stack feature and bootloader support and uses RTS/CTS hardware flow control signals for EZSP-UART/ASH communication.
• em260-uart-xon-xoff-with-bootloader.hex contains full stack feature and bootloader support and uses XON/XOFF in-stream control bytes for software flow control during EZSP-UART/ASH communication.

Note that bootloader hex files for the SPI and UART flavors are also included, such that module vendors (who may not know which NCP firmware is appropriate for their end customers) can load the EM260 with only the bootloader for the expected serial flavor, and the customer can then use either a SIF programmer or a serial link (Xmodem via SPI or UART) to upload the stack-related firmware to the NCP.

You may also notice an image with a filename like “em260-rangetest”. This is used as dedicated firmware image for RF functional test and does not employ EZSP at all. For guidance on how to utilize this Rangetest firmware with the EM260, please refer to Application Note 5041: Bringing Up Custom Devices with EM260, as well as Application Note 5016: Manufacturing Test Guidelines, available in your documentation as a PDF file.