• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 1710 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.

RTOS/CC1310: 15.4 stack stuck after scan request

Andreas Wass
Prodigy 90 points
Part Number: CC1310

Tool/software: TI-RTOS

In non-beacon mode after several hours of sending scan requests the stack seems to get stuck and the scan confirm callback is never called. Any further attempts to send scan requests always returns with scanInProgress error. We have used the example sensor application as base and developed our own sensor from this.

Any advice on how to proceed and how to correct this error?

  • 0
    Prodigy 90 points
    I am SDK version 1.4. Will try SDK version 1.5 as well and see if the issue persists.
  • 0 in reply to Andreas Wass
    Prodigy 90 points

    Using SDK version 1.5 I am seeing the same issue but it appears much faster than with SDK 1.4

    I have tried a simple application that simply sends a scan request every 5 seconds (if no scan request is in progress) and after a couple of hours of scan confirm with no beacons i don't get a scan confirm any longer. Am I missing to free something that must be freed in the scan confirm? What can I do to troubleshoot this more? In its current state the stack is completely unusable apart from the send data and receive data functionality but can even that be trusted?

  • 0 in reply to Andreas Wass
    Prodigy 90 points

    We also see the same issue when using the sensor_cc1310lp example using a CC1310 LaunchPad Rev 1.4 board.

    The following modifications have been done to the config.h file in the example project to more correctly correspond to our own use-case:

    set CONFIG_SECURE false

    set CONFIG_PHY_ID to APIMAC_STD_ETSI_863_PHY_3

    set CONFIG_CHANNEL_MASK to { 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, \
                                            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
                                            0x00, 0x00, 0x00, 0x00, 0x00 }

    Internally we use channel 26 and sometimes channel 0 but I wanted to test this with one of the default enabled channels without interferring with internal testing of other things.

    No collector is present on this channel so we expect to get scan confirms with status noBeacon continuesly. Letting the example run over night we simply stop getting scan confirms at some point which is the same symptoms as with our own code on our own pcb.

    Any help is appreciated since this is a major issue for us.

  • 0 in reply to Andreas Wass
    Prodigy 90 points
    Another observation is that the current consumption is higher (with a few milliA) compared to the normal idle state.
  • 0 in reply to Andreas Wass
    TI__Expert 4375 points
    Hey Andreas,

    What the sensor application does when it tries to join a network in non-beacon mode is this. its performs an active scan (the sensor sends out a beacon request on all channels specified in the CONFIG_CHANNEL_MASK, and listens for a beacon response). Once this scan is complete and no networks are available to join the device sets a timer for CONFIG_SCAN_BACKOFF_INTERVAL. When this timer expires another scan is performed. This way no scan can be started until the confirmation callback is called. Maybe try this implementation to avoid your issue. I have a test running right now to see if I can reproduce your issue. I will get back with what I find out.
  • 0 in reply to Brocklobsta
    Prodigy 90 points
    Hi

    Thanks for the response!

    Yes I know, but as I said, with the above configuration changes (see one of my previous replies) the scan stopped working even with the example sensor application.

    The test setup is: single cc1310 launchpad board running the sensor application with config_security false and using 863 MHz std etsi phy id 3 with a single channel enabled. No collector available. This will cause the sensor application to continuesly send beacon requests when it performs an active scan. After a couple of hours (9 or so?) the board will stop sending beacon requests and trying to force a scan start will simply result in scan already in progress error. The board will be stuck in this state forever and will simply not work until restarted.

    If you need further info or example code/project I will be happy to provide it.

    Regards
  • 0 in reply to Andreas Wass
    Prodigy 90 points

    Any updates on this?

  • 0 in reply to Andreas Wass
    Prodigy 90 points

    Any updates yet?

    What is the results from the testing you did?

  • 0 in reply to Andreas Wass
    TI__Expert 4375 points

    Hey Andreas,

    I have reproduced your issue, and have fixed it by applying the following patch to processIncomingICallMsg in api_mac.c and adding SCAN_MEM_FIX to the predefined symbols:

                case MAC_MLME_SCAN_CNF:
                if(pMacCallbacks->pScanCnfCb)
                {
                    processScanCnf(&(pMsg->scanCnf));
                }
#ifndef SCAN_MEM_FIX
                if(pMsg->scanCnf.resultListSize)
                {
#endif
                    if(pMsg->scanCnf.scanType == ApiMac_scantype_energyDetect)
                    {
                        if( pMsg->scanCnf.result.pEnergyDetect != NULL)
                        {
                            ICall_free(pMsg->scanCnf.result.pEnergyDetect);
                        }
                    }
                    else
                    {
                        if( pMsg->scanCnf.result.pPanDescriptor != NULL)
                        {
                            ICall_free(pMsg->scanCnf.result.pPanDescriptor);
                        }
                    }
#ifndef SCAN_MEM_FIX
                }
#endif
                break;