Known bugs and workarounds

The following is an ad-hoc listing of known bugs and possible workarounds in the Anaren AIR-ZNP software.

Check the Downloads page to see if there are software updates available.

=MSP-430 / STELLARIS AIR-ZNP SOFTWARE (firmware version 1643 11/2/2012)=

Device announce messages displayed incorrectly (minor)
In the Simple Applications Examples - Coordinator, the fields of the Device Announce messages are not displaying properly. There is a bug in the function displayZdoEndDeviceAnnounce. The for loop does not have proper start and ending values. This is due to an incorrect constant in the zdo.h file.

Workaround
Modify zdo.h and zdo.c as shown below. zdo.h line 64:    #define ZDO_END_DEVICE_ANNCE_IND_CAPABILITIES_FIELD                  (SRSP_PAYLOAD_START + 12) zdo.c line 255:   for (i=ZDO_END_DEVICE_ANNCE_IND_MAC_START_FIELD+7; i>=ZDO_END_DEVICE_ANNCE_IND_MAC_START_FIELD; i--)

Fixed
This has been fixed in version 1668 -- which is not yet available.

RGB Color sensor values displayed incorrectly (minor)
In the Simple Applications Examples - Coordinator, the RGB Light Sensor values that are received from an End Device) are displayed as signed integers instead of unsigned integers as they should be. So when then exceed 32767, they will print out as negative numbers.

Workaround
Modify function parseMessages in example_simple_application_coordinator_afzdo.c as shown below. printf("   %s (0x%02X) = %u  ", getOidName(im.kvps[j].oid), im.kvps[j].oid, im.kvps[j].value);    // Display the Key & Value

Fixed
This has been fixed in version 1668

Console output mentions incorrect LED reference designators (minor)
In the Simple Applications Examples - Coordinator, the console output mentions D5 and D6 as being the LEDs which indicate the state of the RGB LED display. In fact, it is D8 and D9 (respectively) that display the state.

Workaround
Modify example_simple_application_coordinator_afzdo.c, lines 243-246 as shown below. printf("Press button to change which received value is displayed on RGB LED. D9 & D8 will indicate mode:\r\n"); printf("   None = None\r\n"); printf("   Yellow (D9) = IR Temp Sensor\r\n"); printf("   Red (D8) = Color Sensor\r\n");

Fixed
This has been fixed in version 1668

Defining ZM_PHY_SPI_VERBOSE causes compiler warnings in zm_phy_spi.c (minor)
If the symbol ZM_PHY_SPI_VERBOSE is defined, the compiler will produce a warning when compiling zm_phy_spi.c because the printHexBytes is not defined.

Workaround
Near the top of the file zm_phy_spi.c (where the other include statements are), add the following line:
 * 1) include "../Common/utilities.h"

Routine zdoUserDescriptorSet has a bug (minor)
The ZDO function zdoUserDescriptorSet in the file zdo.c has a bug where it sets the message length incorrectly before sending the message to the module. This results in one byte not being sent.

Workaround
Modify the file zdo.c, line 345 to read as shown below: zmBuf[0] = ZDO_USER_DESC_SET_PAYLOAD_LEN_HEADER + userDescriptorLength;

Fixed
This has been fixed in version 1817

Project will not build with INCLUDE_RGB_LED symbol undefined (minor)
The Simple Application Coordinator project (and possibly others) does not build properly with the INCLUDE_RGB_LED undefined. It reports several undefined externals when linking.

Workaround
In the file example_simple_application_coordinator_afzdo.c, several sections of code need to be wrapped in #ifdef INCLUDE_RGB_LED / #endif.

static char* getRgbLedDisplayModeName(uint8_t mode);
 * 1) ifdef INCLUDE_RGB_LED
 * 1) endif

halRgbLedPwmInit;
 * 1) ifdef INCLUDE_RGB_LED
 * 1) endif

rgbLedDisplayMode++; if (rgbLedDisplayMode > RGB_LED_DISPLAY_MODE_MAX) {       rgbLedDisplayMode = 0; halRgbSetLeds(RGB_LED_PWM_OFF, RGB_LED_PWM_OFF, RGB_LED_PWM_OFF); }   printf("Setting State to %s (%u)\r\n", getRgbLedDisplayModeName(rgbLedDisplayMode), rgbLedDisplayMode);
 * 1) ifdef INCLUDE_RGB_LED

uint8_t result = setModuleLeds(rgbLedDisplayMode); if (result != 0) {       printf("Error %u setting Module LEDs\r\n", result); }

resetNominalTemperature; resetNominalColor;
 * 1) endif

{                 displayTemperatureOnRgbLed(im.kvps[j].value); }
 * 1) ifdef INCLUDE_RGB_LED
 * 1) endif

displayColorOnRgbLed(RED_VALUE, BLUE_VALUE, GREEN_VALUE);
 * 1) ifdef INCLUDE_RGB_LED
 * 1) endif

/* Displays the pretty name of the LED display mode. @param mode which LED display mode @return name of mode, or "UNKNOWN" if not known */ static char* getRgbLedDisplayModeName(uint8_t mode) {   switch(mode) {   case RGB_LED_DISPLAY_MODE_NONE: return "RGB_LED_DISPLAY_MODE_NONE"; case RGB_LED_DISPLAY_MODE_TEMP_IR: return "RGB_LED_DISPLAY_MODE_TEMP_IR"; case RGB_LED_DISPLAY_MODE_COLOR: return "RGB_LED_DISPLAY_MODE_COLOR"; default: return "UNKNOWN"; } }
 * 1) ifdef INCLUDE_RGB_LED
 * 1) endif

Project may not build with latest IAR EW430 v5.52.1(minor)
The AIR-ZNP projects for the MSP-430G2553 may not build properly in the latest version of IAR -- v5.52.1. This may in fact be an IAR bug. But it is easy to work around.

You will see: Linking Error[e183]: Static overlay map generation (-xo) is not supported for the MSP430 processor. Error while running Linker

Workaround
In IAR EW430, go to Project -> Options -> Category: Linker -> Tab: List. Uncheck the Static Overlay Map checkbox.

clearLed(0) function in hal_launchpad.c does not work (minor)
Calling clearLed(0) does not work. There is a missing tilde in the code.

Workaround
Modify the code to read as follows (adding the tilde).

case 0: P1OUT &= ~BIT0;

=A2530 Z-STACK / ZNP MODULE SOFTWARE (version 2.5.1)=

Router may not rejoin network correctly (Rare)
In rare circumstances it has been observed that a power-cycled Router in close vicinity to another Router may fail to rejoin the network upon power-up. TI has determined that this is a problem in their Z-Stack software. The bug will be fixed in the next Core Stack release (currently scheduled for June 2013). It will then take some time to be incorporated into the Anaren AIR-ZNP software release.

According to TI the basic problem seems to be with the network frame counter:
 * When a device is reset, if not using NV restore, its network frame counter (for its transmitted frames) is reset to 0.
 * Routers save the network frame counter of any neighbor in their neighbor table.
 * When a device is turned off and then on again (if the previous network details are not loaded from NV), it may connect to the network via another parent than before, and be assigned a new short address.
 * Following a device announce, the original parent (from before the off-on) will re-use the same neighbor table entry for the reconnected device, and update it with the new short address. The old frame counter that is saved in the neighbor table for this device is not reset (and this is the cause of the bug).
 * Since security is being used, frames with a frame counter smaller than the last saved frame counter are rejected. This means that now the original parent will reject all messages that are received from the reconnected device, until the frame counter is higher than the value it reached before the reset. This is why you see that frames are being processed eventually after some time.
 * This is also what causes what you observe in the link status messages: since the link status messages from the reconnected device are ignored by the original parent (because of the reason described above), the original parent does not update the respective cost entries in the neighbor table. (so you see in the link status sent by the original parent that it considers the link to the reconnected device as dead).
 * After the network counter reaches the previously saved value, there need to be another link status from the reconnected device so the original parent will process this packet and consider the link as valid.
 * Only after the link is considered valid by the original parent, it will be able to respond to route requests (because route replies are not sent to devices for which we have txCost set to 0 (dead link)).

=A2530 MODULE HARDWARE=

Module pins CFG0 / P1_2 and CFG1 / P2_0 must be connected
The Anaren AIR-ZNP software uses two important control signals that must be set externally. These signals are inputs to the A2530 module and are read on module startup. These pins do not have internal pull-ups or pull-down resistors used so they must be appropriately pulled up or down externally to the module. They cannot be left floating or operation is uncertain.
 * CFG0 / P1_2: Connect this signal to ground.
 * CFG1 / P2_0: Controls serial communication protocol. Connect to logic high to use SPI. Connect to ground to use UART. See Physical Interface for more information.

=DOCUMENTATION=

Conflicting information on module pins 13-16(minor)
In the ...\PCBDesignFiles\AIR BoosterPack Schematic.pdf schematic, A2530 (U6) pins 13-16 are labeled NC. In the ...\Documentation\AIRModuleUsersManual\A2530R24x UsersManual.pdf Users' Manual, these pins are labeled GND. This appears to be a contradiction. In fact, this is an acceptable use of the module, as is explained below.



The A2530x24xZ1Gx pins 1, 3, 12, 13-16, 22, 34, and the metal module cover are each and all connected inside the A2530 module to each other. And while Anaren recommends that all module ground signals be connected to ground it is acceptable to leave these four pins as not connected. The A2530 module will operate properly without an external ground connection on pins 13-16.

Pins 5 and 6 are documented incorrectly in the A2530 User Manual(minor)
In Section 3.3 of both the A2530R24 and A2530E24 Users Manuals, Figure 4 labels pins 5 and 6 incorrectly. These pins are DNC if using the included AIR-ZNP software but may be used if loading your own firmware on the Module. If using your own firmware then these pins should be labeled as follows: If using the Anaren AIR-ZNP software that is preloaded into the A2530 modules then leave these pins unconnected.
 * Pin 5 should be labeled: P2_4 / XOSC32K_Q1
 * Pin 6 should be labeled: P2_3 / XOSC32K_Q2

A2530 Product Briefs incorrectly list Range Test and PER Test
The A2530 Product Briefs incorrectly list two examples in the Features / Firmware section that do not actually exist as part of the software release. There is no Range Test, nor is there a Packet Error Test. Please simply ignore these two items.

