Pico W only connects to WIFI after 2 restarts #1373

New issue

Open

opened 2023-05-12 12:10:35 -05:00 by renedavoh · 3 comments

renedavoh commented

2023-05-12 12:10:35 -05:00

(Migrated from github.com)

99% of the time when i recompile/flash/debug no WIFI connection... after restarting the program (while debugging in VS Code) WIFI will connect.

peterharperuk commented

2023-05-16 12:20:49 -05:00

(Migrated from github.com)

You'll have to add some more information if you want use to do anything with this. If you run it in debug can you capture the logs from the uart? Anything interesting about your wifi? What type of router? Are you close to the router? What's the rssi when you connect? Does waiting longer help? How long does it take to connect when it succeeds? Do any other devices have a problem?

BigRedTower commented

2023-08-21 16:01:43 -05:00

(Migrated from github.com)

I've run into a similar issue, and the solution was to retry the connection to the wifi. ie if the first call to cyw43_arch_wifi_connect_timeout_ms() times out, repeat the call, and it will always work on the second call. The same applies when using cyw43_arch_wifi_connect_async(): if you don't hear back from it, call it again, and it will work the second time. Everything seems to be working fine, it just takes slightly longer to connect. A 12 second retry timeout is what I use.
I'm not convinced this is the Pico's fault, because it appears the AP is refusing to respond to the initial connection request, rather than the Pico not sending such a request. Seems like maybe a security mechanism on the AP's side (hostapd/Pi 3b+) might be doing it. Takes it a moment to realize the old connection is gone before allowing a new connection from the same device.
A clue that it's the AP is that if you call cyw43_wifi_leave() then reboot via watchdog, the next wifi connection attempt is instant, because the AP knows we want a new connection.

I've run into a similar issue, and the solution was to retry the connection to the wifi. ie if the first call to cyw43_arch_wifi_connect_timeout_ms() times out, repeat the call, and it will always work on the second call. The same applies when using cyw43_arch_wifi_connect_async(): if you don't hear back from it, call it again, and it will work the second time. Everything seems to be working fine, it just takes slightly longer to connect. A 12 second retry timeout is what I use. I'm not convinced this is the Pico's fault, because it appears the AP is refusing to respond to the initial connection request, rather than the Pico not sending such a request. Seems like maybe a security mechanism on the AP's side (hostapd/Pi 3b+) might be doing it. Takes it a moment to realize the old connection is gone before allowing a new connection from the same device. A clue that it's the AP is that if you call cyw43_wifi_leave() then reboot via watchdog, the next wifi connection attempt is instant, because the AP knows we want a new connection.

oyama commented

2024-05-03 17:58:47 -05:00

(Migrated from github.com)

I also support @BigRedTower comments. This is not a Pico issue, but a behavioural issue with the Wi-Fi client requirements. If you leave Wi-Fi without calling cyw43_wifi_leave() or cyw43_arch_disable_sta_mode() during shutdown, the AP assumes the client is still present and will refuse the first connection.

Best practice is to retry the connection. If possible, call cyw43_wifi_leave() before shutting down/restarting.

I also support @BigRedTower comments. This is not a Pico issue, but a behavioural issue with the Wi-Fi client requirements. If you leave Wi-Fi without calling `cyw43_wifi_leave()` or `cyw43_arch_disable_sta_mode()` during shutdown, the AP assumes the client is still present and will refuse the first connection. Best practice is to retry the connection. If possible, call `cyw43_wifi_leave()` before shutting down/restarting.