CC2530: Joining issue

Antonio Portaluri

Part Number: CC2530
Other Parts Discussed in Thread: Z-STACK,

Hello,

I use a CC2530 with Z-Stack 1.2.2 as ZigBee coordinator and 50 CC2530 with Z-Stack 3.0.1 that act as routers. I use MTO routing to reduce network messages.

I have serious troubles while joining a new device. I have reset 5 devices and have tried to reconnect them to the network without success.

The procedure stops after the Update Device message as you can see in the attached image; no response from the coordinator.

what could be the problem?

Thanks,
Antonio

over 6 years ago

0 YiKai Chen over 6 years ago

Guru 735695 points

Try to change the value of ZDAPP_UPDATE_NWK_NV_TIME from it's default of 700 (ms) to a larger value, like 3500 on your coordinator to test again.

0 Antonio Portaluri over 6 years ago in reply to YiKai Chen

Intellectual 260 points

Hi YiKai,

thank you for the response. I have tried just now your solution but without success. The 5 devices did not rejoin the network. The joining procedure stops after the Update Device message and I can't see the network key message.

Do you think to update the value also to all routers? Do you have any other changes to try?

In my tests I've seen that the routers with depth 1 still able to join a router; all other routers are not able to join successfully a new device.

Thanks,
Antonio

0 YiKai Chen over 6 years ago in reply to Antonio Portaluri

Guru 735695 points

Yes, I would suggest you to apply the same change to all routers. I would also like to suggest to increase the number of network layer data buffers in nwk_globals.c.

// doubling the size of all the buffers:

// Maximums for the data buffer queue

#define NWK_MAX_DATABUFS_WAITING 16 //8 // Waiting to be sent to MAC

#define NWK_MAX_DATABUFS_SCHEDULED 10 //5 // Timed messages to be sent

#define NWK_MAX_DATABUFS_CONFIRMED 10 //5 // Held after MAC confirms

#define NWK_MAX_DATABUFS_TOTAL 24 //12 // Total number of buffers

0 Ryan Brown1 over 6 years ago

TI__Guru**** 219527 points

The changes YK is recommending is documented in the Zigbee Known Issues Wiki: processors.wiki.ti.com/.../Zigbee_Known_Issues_and_Proposed_Fixes

Previous history for YK's consideration: https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/767247

Regards,
Ryan

0 Antonio Portaluri over 6 years ago in reply to Ryan Brown1

Intellectual 260 points

Hi,

thank you to all. With the suggested modification I can see an improvement. Now I'm able to connect about 40 devices, then I see again the problem, so I'm doing some tests to refine the MACRO values to reach my goal.

But from the sniffer log, I notice a strange behavior: I see some routers send a Leave message after a Route Request message without response (see the attached image).

How can I fix?

Regards,
Antonio

0 Ryan Brown1 over 6 years ago in reply to Antonio Portaluri

TI__Guru**** 219527 points

Hi Antonio,

Glad to hear that you are making progress. What is the value of ROUTE_DISCOVERY_TIME? It appears that your discovery time is expiring without finding a route to the concentrator, thus the router is opting to leave the network. Attaching sniffer logs is always appreciated.

Regards,
Ryan

0 YiKai Chen over 6 years ago in reply to Antonio Portaluri

Guru 735695 points

Does the joining router far away from your coordinator?

0 Antonio Portaluri over 6 years ago in reply to YiKai Chen

Intellectual 260 points

Hi,
sorry for the late reply.

The routers are all in the same room, so no distance issue.

In the routers' firmware, the ROUTE_DISCOVERY_TIME has the default value: 5.

Do you think I have to increment this value?

Thanks,
Antonio

0 Ryan Brown1 over 6 years ago in reply to Antonio Portaluri

TI__Guru**** 219527 points

Try increasing to see if there are any changes. To YK's point there could be a hardware issue more than physical distance. It's difficult to debug the communication when only filtered sniffer log screenshots are provided.

Regards,
Ryan

Zigbee & Thread

Zigbee & Thread forum

CC2530: Joining issue