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.

RTOS/CC2652R: In every version SDK of CC2652R,the timestamp of macMcpsDataCnf_t in message MAC_MCPS_DATA_CNF is invalid.

Part Number: CC2652R
Other Parts Discussed in Thread: CC2630, Z-STACK, SIMPLELINK-CC13X2-26X2-SDK,

Tool/software: TI-RTOS

I have found this issue in simplelink zigbee v1.60.00.14 and v1.60.01.09 and v2.20.00.06 and v2.30.00.34.

I put a break point in function MAC_CbackEvent in file zmac_cb.c, to capture message MAC_MCPS_DATA_CNF. Then check this message as struct macMcpsDataCnf_t. Other members of macMcpsDataCnf_t is correct, such as hdr->status, msduHandle, mpduLinkQuality. But timestamp will not changes after very Zigbee packet send and returns an incorrect value .

  • Was the previous response to this inquiry not satisfactory? e2e.ti.com/.../736993

    Please explain what you are seeing versus what you expect to observe.  Keep in mind that txTime is relative to the reference time (start of the superframe) and not absolute time.  If timestamp does not change and timestamp2 changes it means that the data is transmitted at similar time point relative to the reference time.

    Regards,
    Ryan

  • This issue is happened in my CC2652 board. My code will capture the message MAC_MCPS_DATA_CNF in MAC_CbackEvent, and timestamp(32bit type) returns a constant value after very sending. But the timestamp value of macMcpsDataInd_t when MAC_MCPS_DATA_IND incoming will returns an valid value.

    long long ago, I have test it on z-stack home 1.2.2a for CC2630, the timestamp of MAC_MCPS_DATA_CNF is a valid value. When MAC_MCPS_DATA_CNF is incoming, the back-off time of CC2630 is read, and the value is 3 or 4 later than timestamp value.

  • Can you please provide a sniffer log or captured data images to further demonstrate the problem?

    Thanks,
    Ryan
  • This issue has no relation with over-air packet, so the sniffer could not detect it.

    I provide my test code

    uint32 TxTimestamp[256];
    uint16 TxTimestamp2[256];
    uint8 TxTimestampCnt;
    void MAC_CbackEvent(macCbackEvent_t *pData)
    {
      uint8 event = pData->hdr.event;
      uint16 tmp = zmacCBSizeTable[event];
      macCbackEvent_t *msgPtr;
      bool gpDataCnf = false;
    
      /* If the Network layer will handle a new MAC callback, a non-zero value must be entered in the
       * corresponding location in the zmacCBSizeTable[] - thus the table acts as "should handle"?
       */
      if (tmp == 0)
      {
        return;
      }
    
      if ( event == MAC_MCPS_DATA_CNF )
      {
        TxTimestamp[TxTimestampCnt] = pData->dataCnf.timestamp;
        TxTimestamp2[TxTimestampCnt] = pData->dataCnf.timestamp2;
        TxTimestampCnt++;
      }
    
      ......
    
    }

    after my code is running, the value of TxTimestampCnt is 8.

    TxTimestamp shows these value

    TxTimestamp2 shows these value

  • This issue is only appearing on CC2652, my chip is REV C, can U offer me REV E to make sure this issue?
  • Thank you for providing the information as requested, I have replicated the behavior on a CC2652R Rev E device with the SIMPLELINK-CC13X2-26X2-SDK and am asking the SW Development Team to further investigate.

    Regards,
    Ryan
  • Aries,

    Thank you for your patience during the delay to address this bug, the root cause of this issue is due to reading from wrong place to get macTxTimestamp. This was caused while migrating the 15.4-Stack from Sub-GHz to 2.4 GHz bands, in which the source of macTxTimestamp was not changed based on the difference in bands. It is a core-level change which will be addressed in the next SDK release.

    Regards,
    Ryan