• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 39 subscribers
  • Views 617 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.

CC3220: Handling disconnect events when calling sl_Select() with an infinite timeout period in FreeRTOS

V Velasco
Prodigy 240 points

Part Number: CC3220

We're running our application under FreeRTOS on a CC3220SF.   Because we can't use trigger mode in FreeRTOS, and because we need to minimize the idle current, we're using an infinite timeout period when calling sl_Select(). That is, we set the timeout parameter to NULL.

However, I discovered that if the WiFi network is disconnected (that is, if a disconnect event occurs), sl_Select() remains blocked instead of returning.  What would be the best way to handle such situations?  Is there some way we can make sl_Select() return when a disconnect occurs?

  • 0
    TI__Expert 8255 points
    Hi Velasco,

    Is it possible to structure your application as is done in the thread linked below? This would require creating a finite timeout for sl_select, which is called in a loop and exiting based on the return value.

    e2e.ti.com/.../373703
  • 0 in reply to Austin Tanner
    Prodigy 240 points

    Only as an absolute last resort. We want to minimize the power consumption by sleeping for as long as possible.  Having to repeatedly poll sl_Select()'s return value would naturally defeat this approach.

  • 0 in reply to V Velasco
    Prodigy 240 points
    Just following up on this. As I said, using a finite timeout would be an absolute last resort, since we do want to minimize the power consumption.

    Would calling sl_Stop() and then sl_Start() upon detecting a disconnect event be a reasonable approach, for example? Any other methods?
  • 0 in reply to V Velasco
    TI__Expert 8255 points

    Hi Velasco,

    It would not be good practice to call sl_stop and sl_start. This is because the SL host driver uses objects to synchronize certain events via pending and posting a semaphore. Calling sl_stop and sl_start will not reset the state of these objects--which can cause problems when the host starts to communicate with the NWP again.

    So, the safest course of action would be to assign a finite timeout when calling sl_select--long enough to take advantage of power savings, but short enough to recover if a disconnect event occurs.