• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 40 subscribers
  • Views 1494 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC3220S-LAUNCHXL: Why it can jump out the sem_wait_timeout without both the sem_post and timeout?

XiaozhongZhang
Expert 1925 points
Part Number: CC3220S-LAUNCHXL

I'm using network terminal project, my step is as below:

1. connect an AP use wlanconnect command

2. power down my AP, it will print the message  Device disconnected from the AP: LMServerAP

3. connect the AP again, it will reach line 174(code after sem_wait_timeout) at the picture below immediately , but now timeout(it is 6 seconds) is not reached, and  sem_post(&app_CB.CON_CB.connectEventSyncObj); also has not been done,

why it can go ahead and not block in sem_wait_timeout.

The first time I connect the AP it worked normally, it will sem_post firstly then unblock the sem_wait_timeout! But once I connected AP and restart the AP , connect the AP again, the phenomenon will occur!

  • 0
    TI__Mastermind 30780 points

    Hi,

    What units is your WLAN_EVENT_TOUT defined in? I believe the sem_wait_timeout() takes a value in milliseconds.

    Please also check what value you get when you call sem_getvalue() on the semaphore to make sure the value is what is expected when you try to pend on it.

    Best Regards,

    Ben M

  • 0 in reply to Benjamin Moore
    Expert 1925 points

    #define WLAN_EVENT_TOUT             (6000) in wlan_cmd.c, so it will wait me with timeout 6000 milliseconds

    the code is network_terminal in SDK and I do not change the code in any place.

    the function sem_wait_timeout is designed as below, it do not use the sem_getvalue, I'm not sure if something wrong with function sem_wait_timeout

    int32_t sem_wait_timeout(sem_t *sem, uint32_t Timeout)
    {
    struct timespec abstime;
    abstime.tv_nsec = 0 ;
    abstime.tv_sec = 0 ;

    /* Since POSIX timeout are relative and not absolute,
    * take the current timestamp. */
    clock_gettime(CLOCK_REALTIME, &abstime);
    if ( abstime.tv_nsec < 0 )
    {
    abstime.tv_sec = Timeout;
    return (sem_timedwait(sem , &abstime));
    }

    /* Add the amount of time to wait */
    abstime.tv_sec += Timeout / 1000 ;
    abstime.tv_nsec += (Timeout % 1000)*1000000;

    abstime.tv_sec += (abstime.tv_nsec / 1000000000);
    abstime.tv_nsec = abstime.tv_nsec % 1000000000;

    /* Call the semaphore wait API */
    return sem_timedwait(sem , &abstime);
    }

  • 0 in reply to XiaozhongZhang
    TI__Mastermind 30780 points

    Please clarify this point about your test - When you restart the AP, are you inputting the wlanconnect command again or is the device automatically connecting to the AP?

    When I run the example through this test case:

    1. Connect to AP by calling wlanconnect
    2. Power down AP (and see disconnect event)
    3. Power up AP
    4. Call wlanconnect command again

    I see the connect semaphore get posted to again from the callback.

    Thanks,

    Ben M

  • 0 in reply to Benjamin Moore
    Expert 1925 points

    Yes, I really can get semaphore posted to again from the callback. But what confused me is it jump over the sem_wait_timeout immediately when I call wlanconnect command(now the post do not happened yet). Wait a short time, the semaphore will post when the SL_WLAN_EVENT_CONNECT happened. 

  • 0 in reply to Benjamin Moore
    Expert 1925 points
    I input the wlanconnect command again, I not use the device automatically connect to the AP
  • 0 in reply to Benjamin Moore
    Expert 1925 points
    Hi, could you answer my question?
  • 0 in reply to XiaozhongZhang
    TI__Mastermind 30780 points

    Hi,

    I performed the following test and found no issue:

    1. Run Network Terminal example

    2. Call wlanconnect to a known AP (successfully connected)

    3. Power down the AP to cause a disconnect event

    4. Call wlanconnect on an AP that does NOT exist to cause the system to wait at the "sem_wait_timeout()" call in cmdWlanConnectCallback.

    The system stays at the sem_wait_timeout call for the appropriate amount of time before timing out. When I perform step (4) with the original AP, I also wait as expected until I see the SL_WLAN_EVENT_CONNECT event which causes the sem_post(). 


    Do you have any more details on your test that I could be missing in mine? 

    Thank you,

    Ben M