esp_restart() from esp_timer callback doesn't work in 3.1.3

[ESP_igrr]

The issue here might be that you are trying to call esp_restart from the timer callback, and esp_restart will call esp_wifi_stop. It is possible that esp_wifi_stop does not work from a timer callback; only from a task. Can you try moving esp_restart from a timer callback into your application task?

[phatpaul]

Thanks igrr,
Yes I tried call esp_restart() from my http server task, it works. (currently testing in 3.2)

So is this an expected limitation? I guess I have to move my reset push-button handler to a task?

[ESP_igrr]

Although undocumented, currently it is indeed an expected limitation. I will create a ticket to look into lifting it. However for now it's better to move the restart handler out of the timer callback.

[ESP_Angus]

One addition to Ivan's comment: If you still want to restart from a timer callback, and you don't need a high precision timer which runs at a high FreeRTOS priority, then you can use a FreeRTOS timer to call esp_restart(). That should work with no other changes.
https://docs.espressif.com/projects/esp ... Function_t

[Ritesh]

The issue here might be that you are trying to call esp_restart from the timer callback, and esp_restart will call esp_wifi_stop. It is possible that esp_wifi_stop does not work from a timer callback; only from a task. Can you try moving esp_restart from a timer callback into your application task?

Yes.

But, he has checked issue into TAG 3.1.1. in which same functionality is working fine without any issue.

[ESP_Angus]

But, he has checked issue into TAG 3.1.1. in which same functionality is working fine without any issue.

Yes. The most likely root cause is the following (from the 3.1.2 release notes):

• Add a timer which is started by esp_wifi_stop(). Stop Wi-Fi forcibly once the timer expires.

esp_restart() now calls esp_wifi_stop() which tries to start its own timer (via esp_timer) that may be needed before wifi stop can complete, but as the first esp_timer callback is still running the WiFi stop timer callback will never run. (Most likely the reason that the WiFi stop timer callback is needed is also related to esp_timer being blocked, as Wi-Fi uses esp_timer for a number of purposes.)

esp_timer callbacks are not quite as sensitive as ISRs, but they should be treated as almost as sensitive - ie to avoid any complex processing happening from inside them. I think the documentation doesn't stress this enough.

The solution, as per previous posts, is to either trigger the shutdown to happen from another lower priority task which doesn't block esp_timer, or to use a FreeRTOS timer (which runs in a lower priority timer task).

[Ritesh]

But, he has checked issue into TAG 3.1.1. in which same functionality is working fine without any issue.

Yes. The most likely root cause is the following (from the 3.1.2 release notes):

• Add a timer which is started by esp_wifi_stop(). Stop Wi-Fi forcibly once the timer expires.

esp_restart() now calls esp_wifi_stop() which tries to start its own timer (via esp_timer) that may be needed before wifi stop can complete, but as the first esp_timer callback is still running the WiFi stop timer callback will never run. (Most likely the reason that the WiFi stop timer callback is needed is also related to esp_timer being blocked, as Wi-Fi uses esp_timer for a number of purposes.)

esp_timer callbacks are not quite as sensitive as ISRs, but they should be treated as almost as sensitive - ie to avoid any complex processing happening from inside them. I think the documentation doesn't stress this enough.

The solution, as per previous posts, is to either trigger the shutdown to happen from another lower priority task which doesn't block esp_timer, or to use a FreeRTOS timer (which runs in a lower priority timer task).

Thanks for providing updates regarding same. We will also take care while using that IDF version as esp_restart API is necessary or required call for any application.