Esp-idf: Add a way to deinit tcpip_adapter (IDFGH-2541)

[allard-potma]

Is your feature request related to a problem? Please describe.
I'm using IDF version 3.3
When I deinit WiFi using the recommended steps, the tcpip_adapter keeps running. Using auto-light sleep causes the esp to wakeup very often to handle the tcpip_thread, resulting in a higher average power draw. Because the WiFi adapter is de-initialized there is no need to process the tcpip_thread anymore.

My current application suspends the tcpip_thread after the Wifi deinit, but i'm not sure this is save to do?
vTaskSuspend(g_lwip_task);

EDIT: It seems that just suspending the tcpip_thread is not save to do. Occasionally I get a interrupt watchdog reset when entering light sleep:
W (65) boot: PRO CPU has been reset by WDT.
W (65) boot: WDT reset info: PRO CPU PC=0x40081761
0x40081761: .check_dport_access_end at D:/msys32/home/Allard/esp/esp-idf/components/esp32/dport_panic_highint_hdl.S:180

W (65) boot: WDT reset info: APP CPU PC=0x40089453
0x40089453: panicHandler at D:/msys32/home/Allard/esp/esp-idf/components/esp32/panic.c:715

Describe the solution you'd like
A way to safely suspend/resume (or deinit) the tcpip_tread.

[rebeliousconformist]

+1

[david-cermak]

Hi @allard-potma

Thanks for posting this request. I see that the deinit of the network subsystem is highly desirable, this was reported before so linking possible duplicate https://github.com/espressif/esp-idf/issues/1999

There has been partial progress here: now it is possible to deinitialize the esp_netif. However it is still not possible to deinitialize the LwIP stack.

We will however not provide deinitialization function for tcpip_adapter, which becomes deprecated in v4.1.

[allard-potma]

It seems like the "on-demand timer" lwIP addition in IDF v4.0 will solve the high current consumption in light sleep, time for an upgrade when it reaches the stable status.

For IDF v3.3 i've been able to make suspending the tcpip_thread work using the tcpip_callback, call from a thread:

tcpipTaskSuspended = 0;
tcpip_callback_with_block(tcpIpSuspendCallback, 0, 1);

while(tcpipTaskSuspended == 0)
{
    vTaskDelay(2);
}

The function tcpIpSuspendCallback is then called in the tcpip_thread context.

void tcpIpSuspendCallback(void *arg)
{
    tcpipTaskSuspended = 1;
    vTaskSuspend(NULL);
    sys_restart_timeouts();
}

This suspends the tcpip_thread, and when its resumed again all timers are reset. The tcpip_thread can be resumed using:

if(g_lwip_task != NULL)
    vTaskResume(g_lwip_task);

with g_lwip_task declared as extern inside the file:
extern xTaskHandle g_lwip_task;

[daniel-grabner]

+1 on this feature request

I have a similar requirement: I am operating the ESP32 in WIFI station mode and want to reconnect to a different AP without restarting the device. Thus I need to disconnect, stop and deinit the wifi driver before initializing wifi driver again. This does not work without deinitializing the network subsystem as well.

@david-cermak you are writing that it is now possible to deinitialize the esp_netif. Indeed esp_netif_deinit() function still returns ESP_ERR_NOT_SUPPORTED (tested with 4.1 branch and master branch this week). Am I missing something here? Or is there another way to connect to a different AP without the need of restarting netif? Thanks!

[Hantsch]

+1 on this feature request

[Adamantinu]

+1

[hansn57]

+1

[david-cermak]

Thanks everyone for voting for this feature. Let me just better understand the reasoning why is this item so high on demand, as to me it seems like a useful, clean way to destroy the app, but still something not that critical at least not in an embedded environment.

• As @daniel-grabner asks for a connect to another AP -- no need to even restart the netif itself (which is also supported), just reset the wifi config:

    // when already connected
    ESP_ERROR_CHECK(esp_wifi_disconnect());
    ESP_ERROR_CHECK(esp_wifi_set_config(ESP_IF_WIFI_STA, &wifi_config));
    ESP_ERROR_CHECK(esp_wifi_connect());

• The same way it is possible to setup/destroy a separate instances of esp-netif, should it be a wifi or ethernet or any other custom network interface without a need to init-deinit tcp/ip stack
• If someone is concerned about low-power, there's this config option LWIP_TIMERS_ONDEMAND allowing to drop the power consumption to minimum.

I agree that having a proper way to deinit a tcp/ip stack is a good thing, but the LwIP, the underlying stack we use doesn't support this. (that's the ESP_ERR_NOT_SUPPORTED return value for now, when supported upstream, could be easily added to esp-netif)
Yes, it could be added now as well, the esp-lwip fork could be modified to get the deinit functional. We are also trying to reduce the number of espressif specific patches to lwip, though.

Please could you elaborate on a specific use-case where the esp_netif_deinit() would be essential? Just trying to understand the request in a bit more context before i'd go and patch the lwip. Maybe it was just about restarting a wifi, reconnecting, resetting a netif, preventing lwip thread to employ timers in low power, etc... which can done no matter if TCP/IP stack deinits or not.

[allard-potma]

For me it was just the low-power concern, I see no other needs to deinit tcpip.

[daniel-grabner]

For me it was just the requirement to reconnect to a different AP. For some reason this did not work for me when I tested it. Now it works, so no need anymore for deinitializing the IP stack. Thanks @david-cermak for the code snippet!