• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 55 subscribers
  • Views 229 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: ZED polling parent, but parent doesn't seem to have it as child

Akhilesh Premkumar
Expert 1005 points
Part Number: CC2652P

Tool/software:

Hi,

I am facing a weird issue. I have a ZED which is periodically polling its parent and the parent is ACK the poll as well.

However the parent ZR doesn't accept any messages for the ZED. The parent announce from the ZR also doesn't mention this aforementioned ZED.
It seems like the ZR doesn't regard this as a child, but why is it still acking the POLL

This happens very randomly and rarely, but since the ZED is battery powered, we need to force a rejoin somehow to fix it.

Stack: 6.10.00.29
I have attached a screenshot to show the behaviour. the ZED is not a TI device but the ZRs are.

Any advise on why this could be happening will be useful

Thanks
Akhilesh


  • 0
    TI__Guru**** 217867 points

    Hi Akhilesh,

    I will look into this.  If possible, please recommend how this can be easily replicated using only TI LaunchPads.

    Regards,
    Ryan

  • 0
    TI__Guru**** 217867 points

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

    For example, I configured a ZED with a End Device Timeout of 2 minutes and a poll rate of 5 minutes in the F2 SDK v8.30.01, and found that the ZC properly aged out the ZED device and asked it to Leave with Rejoin enabled when the ZED did not report within 2 minutes with a Data Request.  Note that a MAC ACK was present to let the ZED know that the Leave message was incoming.

    I realize that our setups have distinct similarities.  Have you considered testing the latest v8.30.01 SDK to observe whether behavior is the same?  As the ZR does not accept APS or ZCL messages from the ZED, can the ZED firmware be changed to account for this erratic behavior.  I'm not sure which variables are a part of the random and rare behavior expressed on your side.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Expert 1005 points

    On the routers we have disabled child aging. 
    This ZED is an off the market device with no option to update the firmware. 
    I am also considering the update to 8.30.01 SDK for ZRs to check, but unfortunately the issue is not easily reproducible. 

    I have tried restarting the ZR when this happens to clear any remnant data that could be there on it, but it restarted in time before the next poll and this continued to happen. 
    When i turned it off longer than the ZED poll the ZED rejoined to another device and then everything started working fine.

    Is this because this is MAC level and parent-child relationship isn't being checked by the ZR. 
    I don't think it is a concern with the ZED because of the ACK, it is assuming the parent exists. 

    I have disabled child aging on the routers, could this have any impact ?


    Thanks

    Akhilesh

  • 0 in reply to Akhilesh Premkumar
    TI__Guru**** 217867 points

    If the ZR have disabled child aging then they will never remove children unless the ZED rejoins another parent which broadcasts a parent announce.  Is there no Leave Request sent by the ZR, or any changes to NWK keys during this time?  How many ZEDs are joined to this ZR?  What is the network frame counter of the ZED and ZR.  Can you provide a sniffer log which captures the time around which the ZR stops responding?  More information or replication steps are required.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Expert 1005 points

    I understand that will never remove children unless a parent announce happens. The question here is if the ZR's parent announce doesn't have this child ZED why is it returning Ack for Data Request.

    No nwk key changes. 2 ZEDs are joined to this ZR as shown in the screenshot. 
    I do not have the capture exactly when this issue happened, have now enabled an auto-capture and am waiting for the issue to happen again. Will share the logs then.

    What would happen in this case, since child aging is disabled, after a power cut in the house if multiple devices perform parent announce for the same child(i know it shouldn't but in case it does).
    Does the last one take effect ? while the child maybe still connected to other parent ?

    Thanks for your inputs, will update once i have logs when the issue happens again for a more definitive analysis on this

  • 0 in reply to Akhilesh Premkumar
    TI__Guru**** 217867 points

    I agree that the ZR should not be ACKing the data requests of a child ZED it does not recognize.  Can you provide a screenshot of the sniffer's Parent Announce from the ZR?  Are you able to debug the ZR device and read out the association table?

    I would argue that the last parent to send out a parent announce would take effect, although I'm not sure how one ZR would send out a parent announce with the ZED included if it has previously received a parent announce including the ZED from another ZR. In theory if all ZR broadcasts were sent at the same time then this could cause the ZED to be removed from all ZRs simultaneously.  This wouldn't be critical so long as the ZED recognizes that it needs to rejoin any ZR.

    Regards,
    Ryan