Wifi wasn't actually stopped after receiving the WIFI_EVENT_STA_STOP

[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?

[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).

[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.

[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++.