• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 102 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.

CC2652P: Device has a probability of data request not being issued properly

Alex Zhang
Intellectual 1175 points
Part Number: CC2652P
Other Parts Discussed in Thread: SIMPLELINK-CC13XX-CC26XX-SDK

Sdk version: Simplelink_cc13x2_26x2_sdk_5_10_00_48

Device type: Enddevice

There is a probability that a data request will stop sending while the device is communicating, and enddevice will not trigger a lost parent callback, as shown in the following figure.

The device data request is normal before line 5560 and the packet grabber is not catching the data request after line 5560. The data sent by the coordinator is also not received by enddevice

Our application layer controls the poll rate as follows.

        case FAST_POLL:
            nwk_GetCurrentPollRateType(&currentPollRateType);
            if(currentPollRateType != POLL_RATE_TYPE_APP_1)
            {
            nwk_SetCurrentPollRateType(0xFFFF, FALSE);
            nwk_SetCurrentPollRateType(POLL_RATE_TYPE_APP_1, TRUE);
            }
            break;
        case LONG_POLL:
             nwk_GetCurrentPollRateType(&currentPollRateType);
            if(currentPollRateType != POLL_RATE_TYPE_DEFAULT)
            {
             nwk_SetCurrentPollRateType(0xFFFF, FALSE);
             nwk_SetCurrentPollRateType(POLL_RATE_TYPE_DEFAULT, TRUE);
            }

Please help to see if there is a problem? 

  • 0
    TI__Guru**** 192681 points

    Hi Alex,

    Is this issue capable of being easily recreated on the latest SDK (i.e. SIMPLELINK-CC13XX-CC26XX-SDK v7.10) with an example project?  How long does the application operate before this problem is observed?  What is the poll rate of the ZED?  It appears to be quite fast based on the timestamps available from the screenshot.  Can the sniffer log file be provided?  Based on the description, it would appear that the ZED has crashed which could indicate a memory leak or overflow.  I'm not certain that this similar behavior could be replicated when using the updated method and the newest software resources.  Here is an example from zcl_samplesw.c:

            // set poll rate to POLL_RATE after joining
        zstack_sysConfigWriteReq_t writeReq = { 0 };
        // Set the new poll rates
        writeReq.has_pollRate = true;
        writeReq.pollRate = POLL_RATE;
        writeReq.pollRateType = POLL_RATE_TYPE_DEFAULT;
        Zstackapi_sysConfigWriteReq(appServiceTaskId, &writeReq);
        // disable response and queued poll rates
        writeReq.pollRate = POLL_RATE_MAX;
        writeReq.pollRateType = POLL_RATE_TYPE_QUEUED;
        Zstackapi_sysConfigWriteReq(appServiceTaskId, &writeReq);
        writeReq.pollRateType = POLL_RATE_TYPE_RESPONSE;
        Zstackapi_sysConfigWriteReq(appServiceTaskId, &writeReq);

    Regards,
    Ryan

  • +1
    TI__Guru**** 192681 points

    Alex,

    This thread will be continued from this duplicate E2E post: https://e2e.ti.com/f/1/t/1229532 

    Regards,
    Ryan