How do I inspect the version of firmware in a file or loaded on my device?

For various reasons, a developer or field technician may want to inspect a device with an InSight Adapter or InSight USBLink programmer to assess which version of software it is running (rather than querying the device at runtime through software). Alternatively, a developer/technician may have a catalog of EBL or HEX files for EM2xx chips, and he/she wants to determine which files are newer, and perhaps even which versions of firmware those files represent.

One use case is an EM250 programmed with a custom application image, where multiple versions with different timestamps may exist, so the technician wants to know which devices are running which versions. For this use case, simply comparing the timestamps of the firmwares’ builds is sufficient, since the xIDE post-build step (through its em2xx_convert.exe command) incorporates this timestamp in the EBL header as it produces an EBL file.

Another use case is to examine an EM260 Network CoProcessor [NCP], which is loaded with a pre-built EZSP binary, and determine which EmberZNet version the EZSP image is based upon.

So how do we extract the build date timestamp from the EBL header, which is located inside the EBL or HEX file (or inside the node itself)?

Well, based on the hal/micro/xap2b/em250-ebl.h file, we know that the timestamp of the EBL file is located at bytes 0×08-0×0B in the EBL header (which means those same byte positions can be inspected in the *.EBL firmware file as well, if you have that). If you’re examining a HEX dump, either one produced with em2xx_convert.exe against the EBL file, or one created spontaneously by dumping the EM2xx chip’s flash contents with em2xx_read.exe, the EBL header’s timestamp data can be found beginning at hex position 0×00002848 in the HEX file for images with a 10KB bootloader footprint (like the EZSP-SPI firmware with standalone bootloader) or hex position 0×00001448 in the HEX file for images with a 5KB bootloader footprint (like the EZSP-UART firmware with serial-only bootloader). (See http://en.wikipedia.org/wiki/Intel_HEX for a description of the Intel Extended 16-bit HEX file format, which is what the EM2xx platforms use.)

Once we have a 4-digit timestamp, which is an “epoch-based” value corresponding to the number of seconds elapsed since January 1, 1970, we can derive the build time. A helpful utility at http://www.epochconverter.com can assist with this conversion.

For example:
Examining the HEX file content of em260-spi-with-standalone-bootloader.hex from EmberZNet 3.3.4 (EM260) GA release, we find it has an EBL timestamp of 0×4A40DA85. This represents 1,245,764,229 seconds since the epoch (1/1/1970), which breaks down to:

Tue, 23 Jun 2009 13:37:09 GMT

EZN3.3.4 came out on June 23, 2009 (based on examining its release notes), so reading a hex file for an Ember precompiled binary containing this EBL timestamp tells you it comes from a build circa EZN3.3.4.

For convenience, some sample timestamps harvested from past EmberZNet EM260 releases are attached here (listed with timestamp on one line and file patch on the following line). These timestamps were harvested from HEX files in a directory tree by using the following UNIX-style shell script (run from Cygwin or Linux):

find . -name em260\*.hex -exec grep 0000003C....E2.0 {} \; -print | \
awk --field-separator "" '{if ($1 == ".") print $0; else print $26 $27 $28 $29 $30 $31 $32 $33}' \
/dev/stdin   > em260-timestamps.txt

…This works by reading into the HEX file and looking for the start of the EBL header, signified by a string of 00 bytes and the header’s length (0×3C), then offsetting into that line of the HEX dump to find the digits of the timestamp d-word.