Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

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.

CC3230SF: Call to sl_stop() after sl_WlanDisconnect() always times out if not preceded by wait or some other time consuming activity

Part Number: CC3230SF

Tool/software:

I use the following code to shut down the NWP. In my case, SL_STOP_TIMEOUT=15000, but sl_Stop() takes the entire time regardless of what I give it. Also, sl_Stop() returns 0 whether it times out or not.

Without at least a 3ms delay between sl_WlanDisconnect() and sl_Stop(), sl_Stop() will consume the entire timeout time that it is given. 

static void StopWifiTask( void )
{

debug_console_Log(WIFI, LOG_INFO, "StopWifiTask()");
StopRetryTimeout();
StopWifiTimeout();
aws_iot_DisonnectFromAwsIot();
sl_WlanDisconnect();
Task_sleep(6);   // This delay is required so that sl_stop() call won't hang & time out. Not sure why. 2ms is too short, 3ms seems to do the trick
sl_Stop(SL_STOP_TIMEOUT);

}

  • If you call sl_Stop(0), i.e. timeout=0 - it is supposed to return immediately (non graceful termination).

    when timeout is set, the sl_Stop will try to terminate the connection gracefully. If there is an issue during the termination (e.g. peer is not responding to the TCP disconnection) or there was a large buffer of pending data - the sl_Stop will block until the socket is closed (or until the timeout expires).

    Was there any issue with the connection which triggered the StopWifiTask()? 

    If you can capture an NWP log (see chapter 20 of https://www.ti.com/lit/pdf/swru455) we may be able to get more the details on the source of issue.

    An air sniffer log may also help.

  • Thanks for the response, Kobi, 


    Yes, I'm allowing a timeout for sl_stop()  so there can be a graceful termination. However, it appears that it is not gracefully shutting down because whatever timeout I provide, it takes the entire time. I don't know that this is a problem, but it seems curious behavior since no indication is given that anything went wrong. 

    There are no connection issues triggering StopWiFi... I'm doing this on purpose in preparation for hibernation. 

    I'll try to capture the NWP log. I've never done that before, but it will be very useful to see what's going on internally. 

    Thanks again. 

  • Good! I'll wait for the log.

    If you can get the air sniffer log (pcap log from a wi-fi adapter) as well - it would be very helpful.