• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 55 subscribers
  • Views 685 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: UPDATE_DEVICE_IND not triggered when ZHA1.2 device trying to join through another router

Shuyang Zhong
Expert 5105 points

Part Number: CC2652P
Other Parts Discussed in Thread: SIMPLELINK-CC13XX-CC26XX-SDK

A customer is using CC2652P as coordinator working with ZHA1.2 routers and end devices. A problem was found that sometimes a router/end device cannot join through another router. Through the sniffer log and print log we found that the Update Device command was sent in the air but UPDATE_DEVICE_IND was not triggered in ZDApp_ProcessSecMsg:

Please find the sniffer log as attached, in which we can find the unsuccessful Update Device commands on the marked lines(5755/5933/6278/6459/6724/6912):

Also some successful Update Device commands can be found on line 2910 and 7991:

Would you please help analyze what causes the update device commands be ignored? Please let me know if more information is needed for debug, thanks.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/158/2671.cubx

Best regards,

Shuyang

  • 0
    TI__Guru**** 223337 points

    Hi Shuyang,

    What is the SIMPLELINK-CC13XX-CC26XX-SDK version used and ZC example project referenced?  Please note that the ZC permit join must be enabled in order for new devices to join the network, which is likely why it is observed that sometimes devices are able to successfully join whereas other times they are not.  This can be managed with the Zstackapi_ZdoMgmtPermitJoinReq() API

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    TI__Expert 5105 points

    Hi Ryan,

    The SDK is simplelink_cc13x2_26x2_sdk_5_10_00_48, and permit join is turned on when this happens.

    The customer needs more information to debug this, are there other reasons a coordinator could ignore update device command from a router?

    Please let me know if you need more than the sniffer log, thanks!

    Best regards,

    Shuyang

  • 0 in reply to Shuyang Zhong
    TI__Expert 5105 points

    And there is a correction for the description I made: the joining device is not necessarily a ZHA1.2 device, it can also happen to a Zigbee3.0 device, as long as it is joining through a ZHA1.2 router. 

    BR,

    Shuyang

  • +1 in reply to Shuyang Zhong
    TI__Guru**** 223337 points

    The Update Device packet is ignored since APS security is disabled on the ZHA 1.2 device.  Here you can see it compared against another Update Device packet from a ZR which has security enabled:

    This might be changed on the ZC by setting zgApsAllowR19Sec to TRUE inside zglobals.c

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    TI__Expert 5105 points

    Hi Ryan,

    Sorry I clicked "This resolved my issue" by accident, actually this issue is not solved yet.

    The router actually sent 2 Update Device commands everytime, one with security enabled and one with security off. This is for the consideration of backward compatibility of the Zigbee spec. You can find a Update Device on line 7633 right before the one you marked:

    So I don't think this is the root cause. Furthermore, the router sends the same Update Device commands every time, but sometimes it is accepted and sometimes the message is not pushed to the application layer. Can you please help look into the stack and see if there is other reasons the Update Device command is filtered out?

    Best regards,

    Shuyang

  • 0 in reply to Shuyang Zhong
    TI__Guru**** 223337 points

    Thank you for pointing that out, I had not noticed that before but it does appear to be consistent across all ZRs in the network.  I do not see any other reason the Update Device command is filtered out by the latest SDK.  Please confirm this behavior occurs on SDK v7.10 as well.  Also, is there any difference between the 0xD1A4/0x8FBA/0xD144 and the 0x24DF ZRs?  The ZC responds to the Update Device commands from the former but not the latter.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    TI__Expert 5105 points

    Hi Ryan,

    There is no difference between these routers, actually there are cases that the same router can join sometimes and cannot join in another time. Please find another sniffer log to showcase the situation along with the one I sent yesterday:

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/158/2.cubx

    Line 7991 in yesterday's log and line 68 in this attachment show the same device has both successful and unsuccessful joining attempts. The behavior does not vary with the device, so we need to know why the update device command did not trigger the  UPDATE_DEVICE_IND in application layer.

    Best regards,

    Shuyang

  • 0 in reply to Shuyang Zhong
    TI__Guru**** 223337 points

    Given further internal e-mail correspondence, it has been determined that this issue is based on a custom SDK and thus the investigation will be continued offline.  There is no evidence that this behavior exists within the release SDK.

    Regards,
    Ryan