• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 55 subscribers
  • Views 230 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.

Original question:

CC1352P: how to perform mass erase when loading image via UniFlash?

CC1352P: TI-15.4 collector cannot receive data from sensor node(s) while being able to send data to sensor node(s)

Zhiyong Li (FT)
Expert 2760 points
Part Number: CC1352P
Other Parts Discussed in Thread: CC1190, CC1310

Tool/software:

Hi,

We are testing CC1352P and TI-15.4 Non-beacon mode based network and found some weird behavior after a collector node is reset. Most of the time and most of sensor node radios can automatically re-join network after collector node is reset, either caused by power cycle or trigger by external RST pin signal, or a timer triggered system reset through:

Fullscreen
1
SysCtrlSystemReset();
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Occasionally some sensor node in the network can re-join network, but cannot receive any application layer data packet other than tracking packets, sometimes a sensor can re-join network, even receive application layer data a collector node sends to it, but the data packet sensor node sends to collector will not be received by collector node. When this happens, the status code returned by:

Fullscreen
1
2
3
4
5
6
/*!
* @brief MAC Data Confirm callback.
*
* @param pDataCnf - pointer to the data confirm information
*/
static void dataCnfCB(ApiMac_mcpsDataCnf_t *pDataCnf)
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

remains 0x00/success

If this happens, if we manually restart the affected sensor nodes, everything will go back to as expected. But because the returned status code remains 0x00, sensor node itself has no idea those data packets are not actually received by collector. This makes it impossible to manage with code.

My question is, how could this happen? My suspicion is collector node receives those packets but fail to decrypt. 

Please advise,

ZL

  • 0
    TI__Guru**** 211947 points

    Hi ZL,

    Can you please provide a sniffer log which demonstrates the erroneous behavior?  Also, it would be helpful to have the SimpleLink F2 CC13XX / CC26XX SDK version and information as to your network size and any changes which have been made to the default sensor/collector examples.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Expert 2760 points

    Hi Ryan,

    Thanks for your reply.

    The SDK version is v7.41.00.17, with non-beacon mode, and custom-phy. But we had similar problems with CC1310 + CC1190 radio in frequency hopping mode and SDK v4.20. I don't have sniffer log yet, will post back once I have them.

    I also added some debug output in collector node code:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    /*!
    * @brief MAC Data Indication callback.
    *
    * @param pDataInd - pointer to the data indication information
    */
    static void dataIndCB(ApiMac_mcpsDataInd_t *pDataInd)
    {
    if((pDataInd != NULL) && (pDataInd->msdu.p != NULL)
    && (pDataInd->msdu.len > 0))
    {
    Smsgs_cmdIds_t cmdId = (Smsgs_cmdIds_t)*(pDataInd->msdu.p);
    char debugInfo[128];
    #ifdef FEATURE_MAC_SECURITY
    {
    if(Cllc_securityCheck(&(pDataInd->sec)) == false)
    {
    memset(debugInfo, 0x00, sizeof(debugInfo));
    sprintf(debugInfo, "SC failed, srcAddr =%04X", pDataInd->srcAddr.addr.shortAddr);
    atUartOutputDebugInfo(debugInfo, strlen(debugInfo));
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    When a sensor joins network, sometimes even receives data from collector, but the data sent by this sensor node fails to show up on the MCU external to collector radio, I don't observe any of those debug output, indicating dataIndCB is not being called at all.

    Meanwhile, all the status code returned by the following function remains 0x00.

    Fullscreen
    1
    2
    3
    4
    5
    6
    /*!
    * @brief MAC Data Confirm callback.
    *
    * @param pDataCnf - pointer to the data confirm information
    */
    static void dataCnfCB(ApiMac_mcpsDataCnf_t *pDataCnf)
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Taken together, my suspicion is that all the data packets sent by sensor node are somehow lost between MAC and application layer on collector node.

    I recall stumbling upon some post here stating that there is an edge case that if collector resets, sensor nodes may appear to be able to rejoin a network but cannot actually send data, but I couldn't locate that post.

    Regardes,

    ZL

  • 0 in reply to Ryan Brown1
    Expert 2760 points

    The other information that might be relevant is: MAX_DEVICE is set to 150, NVS size is left as default.