Software : Embedded

In terms of the register-based configuration of the Sleep Timer on the EM250 platform, this is very much like using the two general-purpose user timers (Timer1 and Timer2), just with a much smaller set of registers and configuration options…

Sure, you can get a simple reset reason code from halGetResetString(), and with the EM35x HAL you can even get some more verbose description of that reset type through halGetExtendedResetString(), but these only tell you what general variety of reset you experienced.

For certain kinds of resets, it may be useful to just know the approximate program counter (PC) address where the code ended up just prior to the crash. In those cases, the PCDiagnostics routines can be used to pinpoint the last known PC, similar to how this works on Ember’s EM250 platform.

If upgrading to EmberZNet 3.5.x releases of EZSP from earlier (pre-3.5) versions, you may find that your host code now fails to execute any commands after the network coprocessor [NCP] starts up, with the NCP consistently returning these errors about the command not being valid or the version not being properly set. These are likely due a mismatch in the host’s desiredProtocolVersion and the NCP’s own ezspProtocolVersion, which are compared together when the EZSP_VERSION command is executed.

For device replacement in cases where a node fails in the field, you basically have two options:

1. Cloned node method
Clone the non-volatile data in its entirety by taking a HEX dump of the original node (see http://portal.ember.com/hex_dump for guidance on that), including
Manufacturing Token data, and then restoring this HEX dump (overriding
the existing mfg tokens) to the new device, replacing its EUI64 with that of the old node.

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).

Some applications may wish to read their own EBL header tags, as this contains useful data such as a build timestamp and platform settings for the build, which could be used to check for a potentially incompatible image or a recently updated image, or simply provide information to a querying device upon request.

We don’t provide source code to these pre-built functional test applications, such as Rangetest, because they expose sensitive areas of the stack architecture. However, if you need to customize the test behavior of the Rangetest application, or you want similar functionality in a different interface, you can create your own application binary (or incorporate these test features into your existing application to avoid having to load a separate image during the manufacturing test process) by using Ember’s Manufacturing Test Library, known as “mfglib”.

This article explains various techniques for minimizing flash memory consumption for EmberZNet applications developed on the EM250 platform.

NOTE1: This How-To article describes Flash memory conservation techniques. If it is RAM you are concerned about, there are a number of configuration parameters that are variable by the application’s CONFIGURATION_HEADER file and can affect the amount of static memory used by the EmberZNet stack. Please consult the Reducing RAM usage on the EM250 article.