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?
Wifi wasn't actually stopped after receiving the WIFI_EVENT_STA_STOP
Re: Wifi wasn't actually stopped after receiving the WIFI_EVENT_STA_STOP
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).
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
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):
I don't know that this would work, but it might be worth a try.
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
}
}
Re: Wifi wasn't actually stopped after receiving the WIFI_EVENT_STA_STOP
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++.
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++.
Who is online
Users browsing this forum: Baidu [Spider] and 245 guests