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.

CC2652P: ZNP send leave for unsecured rejoin devices

Part Number: CC2652P

Tool/software:

I encountered some issues while using ZNP
Firstly, during the data request on the enddevice device, there was no MAC ack on the ZnP, but during the same time period, another device was functioning normally,what could have caused this?

Because the Lost Mac ack device initiated an unsecured rejoin, but ZNP did not transmit the key as usual, but instead kept initiating a leave rejoin=1,

Why does this phenomenon occur and how can I solve it?Thanks

0xCA36_rejoin_fail.zip

  • Hi jia,

    This is curious behavior.  What version of the SimpleLink F2 CC13X2 / CC26X2 SDK are you using, and have you made any changes to the ZNP firmware?  Does restarting or factory resetting the ZNP improve behavior?  Is the ZED a SimpleLink device as well, and are you able to modify its firmware?

    The ZNP is having much more difficulty sending MAC ACKs to 0xCA36 as compared to 0xBF36.  The ZNP should not transmit a key for a rejoin, but it could expect a Device Announce from the ZED which is not happening.  What is the distance between nodes in this test?

    Regards,
    Ryan

  • SimpleLink F2 CC13X2 / CC26X2 SDK was 5.20 ,except for some network table parameters, nothing else has been modified.enddevice was siliconlabs MG22 also we develop,he is about 8 meters away from the gateway and there is an electric curtain. It is worth mentioning that there are over 100 wifi networks in the on-site environment.we have found a way to avoid it. If this device initiates a secure rejoin again, it can rejoin successfully