• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 55 subscribers
  • Views 458 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: CapabilityFlags in ZDO_JoinIndicationCB is wrong in SDK 6.30

Aries Lord
Genius 5390 points
Part Number: CC2652P
Other Parts Discussed in Thread: SIMPLELINK-CC13XX-CC26XX-SDK, Z-STACK

If a Node's Device type has been change from Router to End Device or from End Device to Router, when it associate with the Coordinate base on SDK6.30. In Coordinate 's ZDO_JoinIndicationCB callback, the CapabilityFlags value is not "CAPINFO_DEVICETYPE_XXXX", it become other wrong value. I have tested that the value is 1 or 2 or4.

  • 0
    TI__Guru**** 219997 points

    Hi Aries,

    Are you using a ZNP to switch the role between a router and end device?  Does this occur before commissioning, and do you factory reset (i.e. clear NV memory) the device before attempting to switch roles?  Generally, it is not possible to switch role dynamically after device joins network.  A router which becomes an end device would be orphaning its children, and end devices which become routers would have superfluous parent information.  Changing roles during runtime would confuse internal NV settings (such as CapabilityFlags stored in the NIB) and other device associations.  Were you able to perform this functionality before SIMPLELINK-CC13XX-CC26XX-SDK v6.30 and how was this accomplished?

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Genius 5390 points

    Yes, the joiner is base on ZNP. I set ZNP as Router an join into coordinate. After joined, erase the NV of ZNP, and set ZNP as End Device, the End Device can't join into coordinate

  • 0 in reply to Aries Lord
    TI__Guru**** 219997 points

    You should send a Leave with rejoin disabled to the Coordinator so that it removes the node entry from its association/routing tables.  Otherwise you will need the ZC to further clean the neighbor tables and children information so it does not recognize the IEEE address of the joining device.  Another option is using a custom secondary IEEE address, or erasing the NV of the Coordinator as well.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Genius 5390 points

    But in real environment, there shuold be any joiners have no enough chance to send a LEAVE-command that can be received by coordinate.

  • 0 in reply to Aries Lord
    TI__Guru**** 219997 points

    Devices which have previously joined are not expected to have changed Zigbee node types and commence a new join.  As such the pre-built Z-Stack security layer is not designed to handle such a use case during commissioning.  Thus users will need to notify the ZC of devices for which table information should be removed.  Would it be possible to perform this after the faulty ZDO_JoinIndicationCB has been received and send a Leave command with rejoin enabled to have the Zigbee node retry commissioning after the ZC has removed the conflicting device information?

    Regards,
    Ryan