Chapter 4. API Guides
• The esp_wifi_scan_start() is called before the scan is completed. A new scan will override the
current scan and a scan-done event will be generated.
The scan-done event will not arise in the following scenarios:
• It is a blocked scan.
• The scan is caused by esp_wifi_connect().
Upon receiving this event, the event task does nothing. The application event callback needs to call
esp_wifi_scan_get_ap_num() and esp_wifi_scan_get_ap_records() to fetch the scanned AP
list and trigger the Wi-Fi driver to free the internal memory which is allocated during the scan (do not forget to do
this!). Refer to ESP32-S2 Wi-Fi Scan for a more detailed description.
WIFI_EVENT_STA_START
If esp_wifi_start() returns ESP_OK and the current Wi-Fi mode is Station or AP+Station, then this event
will arise. Upon receiving this event, the event task will initialize the LwIP network interface (netif). Generally, the
application event callback needs to call esp_wifi_connect() to connect to the configured AP.
WIFI_EVENT_STA_STOP
If esp_wifi_stop() returns ESP_OK and the current Wi-Fi mode is Station or AP+Station, then this event will
arise. Upon receiving this event, the event task will release the station’s IP address, stop the DHCP client, remove
TCP/UDP-related connections and clear the LwIP station netif, etc. The application event callback generally does
not need to do anything.
WIFI_EVENT_STA_CONNECTED
If esp_wifi_connect() returns ESP_OK and the station successfully connects to the target AP, the connection
event will arise. Upon receiving this event, the event task starts the DHCP client and begins the DHCP process
of getting the IP address. Then, the Wi-Fi driver is ready for sending and receiving data. This moment is good
for beginning the application work, provided that the application does not depend on LwIP, namely the IP address.
However, if the application is LwIP-based, then you need to wait until the got ip event comes in.
WIFI_EVENT_STA_DISCONNECTED
This event can be generated in the following scenarios:
• When esp_wifi_disconnect(), or esp_wifi_stop(), or esp_wifi_deinit() is called and
the station is already connected to the AP.
• When esp_wifi_connect() is called, but the Wi-Fi driver fails to set up a connection with the AP due
to certain reasons, e.g. the scan fails to find the target AP, authentication times out, etc. If there are more than
one AP with the same SSID, the disconnected event is raised after the station fails to connect all of the found
APs.
• When the Wi-Fi connection is disrupted because of specific reasons, e.g., the station continuously loses N
beacons, the AP kicks off the station, the AP’s authentication mode is changed, etc.
Upon receiving this event, the default behavior of the event task is:
• Shuts down the station’s LwIP netif.
• Notifies the LwIP task to clear the UDP/TCP connections which cause the wrong status to all sockets. For
socket-based applications, the application callback can choose to close all sockets and re-create them, if nec-
essary, upon receiving this event.
The most common event handle code for this event in application is to call esp_wifi_connect() to reconnect
the Wi-Fi. However, if the event is raised because esp_wifi_disconnect() is called, the application should
not call esp_wifi_connect() to reconnect. It’s application’s responsibility to distinguish whether the event
is caused by esp_wifi_disconnect() or other reasons. Sometimes a better reconnect strategy is required,
refer to Wi-Fi Reconnect and Scan When Wi-Fi Is Connecting.
Espressif Systems 1516
Submit Document Feedback
Release v4.4
To Next Page
Loading...
Need help?
General