This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2650EM-7ID-RD: CC2650 stop sending measurement data packet

Part Number: CC2650EM-7ID-RD
Other Parts Discussed in Thread: CC2538, CC2650, Z-STACK

Hi team , 

We are currently developing a system which using ZED(CC2650) and ZC(CC2538) developed on ZSTACK 1.2.2HA. 

This inquiry is actually related to my previous post below

Issue overview: ZED and ZC binding were successful and data packet were sending and receiving normally at first

but after a few days passed ZED stop sending data packet (measurement data).


We finally managed to reproduce the issue.  

The system is placed in a room with quite unstable zigbee connection. We managed to capture the data packets when zigbee connection lost and found out things as mentioned below:

ZED and ZC binding in EZ-MODE. In the beginning, the data packets were sending and receiving successfully.

Zigbee connection lost occurred, the simplified data packet events were as in attached image below.

(refer attached ubiqua log date July 17th 15:21:05 , packet ID : 8162 onwards)

ZED sent Rejoin Request for 3 times but there was no response from the ZC,

when finally at Rejoin Request (4) there is a Rejoin Response from ZC but ZED only sent measurement packet once then connection became lost again .

After that ZED started to send Association Request and ZC sent Association Response but there was no measurement packet onwards.

When ZED and ZC restarted simultaneously, ZED starts to send data packet as usual.

ZED config file ( is as below:




Here, we also would like to know:

・In the z stack developer’s guide it is stated that when Rejoin failed , the network key is deleted . In this case, does the network key is deleted?

・In what kind of situation does ZED usually send Association Request? Will ZED send it when the network key is unavailable?

・Is there any method to detect in both ZED and ZC when the network key is deleted?

・Can we increase the number of retry for Rejoin Request?  

Any help would be appreciated .

Thank you


  • Hi dalila,

    The sniffer log reflects an issue with the ZC, not the ZED.  As the ZC appears to be suffering from memory issues (NWK key changes to all 0x00 and cannot process incoming packets), have you considered upgrading this CC2538 node to Zigbee 3.0 and implementing the Known Issues and Recommended Fixes?  

    • What you are referring to most likely describes how the network key on the rejoining device will be deleted so that a new join can begin (hence the association requests) after rejoining has failed several times.
    • ZEDs send association requests for a fresh join, and in these instances it will not have the network key.
    • You can use NLME_ReadNwkKeyInfo to get active network key information.
    • This is determined by MAX_RESUME_RETRY in ZDApp, but increasing the number of retries will not be successful if the ZC memory is corrupted.


  • if we only upgrade the ZC zstack to 3.0 but the ZED using the same zstack1.2.2HA is it still possible for both ZC and ZED to communicate with each other ? or do we need to change any setting etc .

  • Z-Stack 3.0 is interoperable with Z-Stack HA 1.2.2a so long as BDB_DEFAULT_TC_REQUIRE_KEY_EXCHANGE is set to FALSE (i.e. define TP2_LEGACY_ZC)