• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 569 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.

CC2652R: Response Wait time

Mathew Heard
Intellectual 741 points
Part Number: CC2652R


This is the communication logs between a ZC (0x0000) and a ZED (TI hardware / stack based, but COTS)

I noticed the device does not stick around after a ZCL command request is issued to receive its response like the ZC expects.

The ZEDs receiver is off until it next issues a data request. Is this the fault of the ZED or the ZC?

  • 0
    TI__Guru**** 219597 points

    Hi Mathew,

    The ZC should be waiting for a Data Request from the sleepy ZED before sending a ZCL Response, especially if it recognizes that the ZED joined as a sleepy end node.  The ZED in turn should be using its Data Response Poll Period if the Check-in ZCL Frame Control "Disable Default Response" bit is zero, although you could set this bit in the ZED to avoid the Check-in Response entirely.  What CC13XX / CC26XX SDK version is being used and did you reference the Poll Control SimpleLink Academy Lab for this observation?

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 741 points

    @Ryan Brown1 The response is a packet sent over serial to ZNP via AF DataRequest.

    Nothing special there. ZED is a regular sleepy ED. ZC is running 6.41.00.17 . What detirmines that a queued packet will need to wait for Data Request. 

    nodeRelation == CHILD_RFD ? I can check the status of that with a debugger.
  • 0 in reply to Mathew Heard
    TI__Guru**** 219597 points

    CHILD_RFD is a reduced function child device, which is as expected.  You will see this in the Association Request's Capability Information (also including Rx On When Idle). 

    All queued packets to these devices will need to wait for a Data Request.  The ZNP should be waiting for this before sending the ZCL response.  Are you using the default ZNP project, and are there other instances where the ZNP/ZC ignores Data Requests before sending AF_DataRequest messages?

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 741 points

    I think this is limited to command responses. So the ZEDs MAC_RESPONSE_WAIT_TIME on the ZED (receiver) is abnormally short? What controls the responder (ZC) side MAC_RESPONSE_WAIT_TIME?

  • 0 in reply to Mathew Heard
    Intellectual 741 points

    I have been able to locate the cause.

    If you call dataRequestSrcRtg with a 0 length route (send to own child) it can create memory corruption which leads to this effect. Its not always but it does happen. Its likely that the non allocated relay is being freeed.