Page 1 of 1

Wifi wasn't actually stopped after receiving the WIFI_EVENT_STA_STOP

Posted: Thu Jun 25, 2020 12:31 pm
by istokm
Hi!
I've ran into a possible edge-case issue. I called esp_wifi_stop() right when the wifi started connecting (literally 20 milliseconds later), I then received the WIFI_EVENT_STA_STOP and tried to start the wifi back up using esp_wifi_start() I received a ESP_ERR_WIFI_STOP_STATE. So it seems like the WIFI_EVENT_STA_STOP event got fired before the wifi was actually stopped.

Attached is a screenshot from the console, the timeout_handler is the one who called the esp_wifi_stop() function, and after receiving the stop event (WIFI_EVENT id: 5) my code (event_handler) tried to start it back up.

Is this something that's (semi-) intentional and I should code checks for it?

Image

Re: Wifi wasn't actually stopped after receiving the WIFI_EVENT_STA_STOP

Posted: Sun Nov 29, 2020 12:15 pm
by Fusion_
How did you end up fixing this?
I currently experience the same problem. Sleeping for 2 sec before trying to connect again fixes the problem, but this is a rather hacky solution. As far as I am aware there is also no way to check if it is still in the `ESP_ERR_WIFI_STOP_STATE` state (other than trying to connect).

Re: Wifi wasn't actually stopped after receiving the WIFI_EVENT_STA_STOP

Posted: Mon Nov 30, 2020 7:06 pm
by mzimmers
It's possible that you're catching a transient state for the WiFi driver. You could put the call to esp_wifi_start() in a small loop (pseudocode below):

Code: Select all

count = 0;
while (rc != ESP_OK)
{
    rc = esp_wifi_start;
    if (rc == ESP_ERR_WIFI_STOP_STATE)
    {
        vTaskDelay(2);
        count++;
        if (count > 3)
            break;
    }
    else
    {
         // some other handling; possibly another break
    }
}
I don't know that this would work, but it might be worth a try.

Re: Wifi wasn't actually stopped after receiving the WIFI_EVENT_STA_STOP

Posted: Mon Mar 22, 2021 2:22 pm
by istokm
For future reference, I've fixed this by rewriting my wifi lib to be completely synchronous. That way, the esp_wifi_start() is not being called inside of the event callbacks, but in a separate synchronous task - this resolved the issue, or, at least I cannot reproduce it anymore.
What I mean by that is that every event, be it generated by the Wifi, User (like calling connect, scan), or anything else adds a event to a queue. That queue then gets synchronously processed in a single task - using a lot of state logic to determine the right actions at the time of processing that event. This has so far been the most stable implementation I've ever worked with.

I unfortunately cannot share the source (yet), but my implementation was heavily inspired by this project . Their state management is on-point, but we didn't use their code, as 80% of the functionality was bloat (due to the whole HTTP portal for management) for our use-cases, the project is no longer active, and we prefer to use C++.