• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 55 subscribers
  • Views 593 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

LAUNCHXL-CC1352P: End device could not rejoin the network

DzungPV
Expert 2090 points
Part Number: LAUNCHXL-CC1352P
Other Parts Discussed in Thread: CC2630, Z-STACK, SIMPLELINK-CC13X2-26X2-SDK

I setup a network with LAUNCHXL-CC1352P as coordinator (znp 3.40) and  some CC2630 end devices (firmware base on sample switch Z-stack 1.2.2).

There are some end device leave the network when signal weak or coordinator lost power, but it could not rejoin the network. It short address is 0x7DBF.

Anybody know how to fix it?

I attach here the packet sniff.ED_not_rejoint.zip

  • 0
    TI__Guru**** 212617 points

    Hi Dzung,

    As apparent through the sniffer log, the ZED is attempting an unsecure rejoin (unencrypted rejoin request packet).  By default the Z-Stack SIMPLELINK-CC13X2-26X2-SDK v3.40 has zgAllowRejoinsWithWellKnownKey set to FALSE in zglobals.c, and since Zigbee HA 1.2.2a devices do not update their TC Link Key from the global default it is unable to join the network.  More information is provided in the Z-Stack User's Guide: http://dev.ti.com/tirex/content/simplelink_cc13x2_26x2_sdk_3_40_00_02/docs/zigbee/html/zigbee/z-stack-overview.html#trust-center-tc-rejoin 

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Expert 2090 points

    Hi Ryan,

    I use code base on SampleSwitch for CC2630 with build tag TC_LINKKEY_JOIN.

    So I just set zgAllowRejoinsWithWellKnownKey to TRUE to allow it rejoin or what i can do with z-stack 1.2.2 project?

    This error is only with 1 of my test device, all other device running the same firmware still rejoin normally.

  • 0 in reply to DzungPV
    TI__Guru**** 212617 points

    Hello Dzung,

    You can observe if the behavior changes when you set zgAllowRejoinsWithWellKnownKey to TRUE, I assume that your other devices still use the NWK key (encrypted packets) when trying to rejoin.  You can provide another sniffer log if this is not the case.  The device in question could have corrupted firmware, inside your application you may need to detect that the rejoin is not successful, reset to factory new, and attempt a fresh join.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Expert 2090 points

    Thank you for the support, i will try your suggestion.