RTOS: Coordinator reset causes the devices to be unable to communicate with it

Tool/software: TI-RTOS

Every time I create a network on a coordinator, it uses the same PANID. The default value used to be 0xFFFF, but I changed it to 0x1FFF, and now the default (and only) value is 0x1FFF. Even after resetting all routing and network related data, the network will always be created with a PANID of 0x1FFF.

What could this issue be caused by? I am using NV_INIT and NV_RESTORE, so that could be related (https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/827261 is another, similar issue I have).

I've combined the relevant threads.  Changing the value of PANID from anything other than 0xFFFF (which then selects a value randomly) will cause that value to be the only one used by the device.  What device, Z-Stack version, IDE version, and example code are you evaluating?  Have you made any changes other than the PANID?

Regards,
Ryan

Ryan Brown1 said:

I've combined the relevant threads.  Changing the value of PANID from anything other than 0xFFFF (which then selects a value randomly) will cause that value to be the only one used by the device.

Oh, I didn't know that, but I was sure that the device was always using 0xFFFF instead, when 0xFFFF value was set, even if I created two networks on two separate devices, so there was no random PANID that I've noticed.

Ryan Brown1 said:

What device, Z-Stack version, IDE version, and example code are you evaluating? Have you made any changes other than the PANID?

The device is cc2642r.
I am using the version of ZStack that comes with 2_20_00_06 ZigBee SDK.
IDE is CCS 8.3.0.
I haven't evaluated or compiled any example code, I inherited this project from another team and it has a ton of legacy code in it, I know for a fact that it was based on some zcl_ example, but I don't know which part controls the settings that are causing the issues I described.

You most likely mean the CC2652R as the CC2642R only supports BLE protocol.  The code source you are referring to is over a year old and with the issues you're experiencing it will be in your best interest to migrate to the SIMPLELINK-CC13X2-26X2-SDK v3.20 with CCS v9.1 and evaluate the examples on a LAUNCHXL-CC26X2R1 Rev E.  http://dev.ti.com/tirex/explore/node?node=AOSQDVXMohlV5LElLx5wxA__pTTHBmu__LATEST 

Regards,
Ryan

Hi Igor,

Do you have any updates to provide or is your issue resolved?

Regards,
Ryan

Hello Ryan. The issue has not been resolved, we realized that porting the application to another version of SDK might cause some other complications so we're leaving that option for if we aren't able to resolve this issue by the end of the month. I will be reading up on the issue more to try to get the head or tails of the issue, it is possible that some of our user configurations might be causing this, and I need to check everything. I've set the value back to 0xFFFF but it is the only PANID that is ever used, even if two devices that could create a network together are made to be coordinators, they have the same PANID which is 0xFFFF. Is there some other option that could be influencing this?

Best regards,

Igor

A PAN ID of 0xFFFF is not valid for Zigbee networks and I am doubtful that the CC2652R device would use it for communication.  Are you able to provide a sniffer log that proves otherwise and displays the issue?  Note that a newer SDK is required for both post-production software/hardware support and you should migrate as soon as possible: https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/767777

Regards,
Ryan

Turns out we were reading wrong memory address, the PANID was fine all along, but the device didn't communicate because the AES key was set again on restart.

I am interested in how exactly the aes key works, because it seems like coordinator and router having the same AES key is not enough, they need to be set the same number of times, too? I will have to delve into this.

So, a summary:

The first time I use the set aes key request, it is always success, but every time other than the first one it reports failure.

Regardless of this, the devices can communicate as long as I set the AES keys on them the equal number of times (whether the function call returns success or failure) and the last key is the same. I should note that I am not using the function to push the change from coordinator to the router, I am talking about manually setting the values separately on both devices, before and after the communication is established.

As for the transition, yes, we're definitely planning on making the transition to the new SDK in less than two months.

Regards,

Igor