ESP32 Forum

Device: ESP32-S3
IDF Version 5.0.1

Issue:
My main code task runs some routines with an external radio, and I'm using a FreeRTOS timer to set timeouts for command responses. I start my WiFi task (which immediately connects to a network) and my main task simultaneously, and I am noticing that very often my main state machine fails because my timer interrupt (for timeout) is executing prematurely at the incorrect time.

I set up a debug print in the RTOS timer handler, and I notice that whenever this happens (timer handler executing prematurely), it's immediately following an action in the WiFi task (IDF's built-in code, not mine): "wifi:state: init -> auth (b0)"

Increasing the timer task's or any other task's stack size has no effect. But what I *did* find is that if I pin the built-in WiFi task (through menuconfig) to Core 1 instead of the default Core 0, this issue goes away.

How in the world could Espressif's WiFi code be interfering with FreeRTOS's timer task (or interrupt handling)? And how could pinning the WiFi task to the app core be changing/remedying this behavior? I welcome any thoughts, things to try, solutions, or promised bug fixes!

Thanks,
Tony

How do you figure the timer callback is being called back *prematurely*? I could explain the callback being *late* (as a higher-priority WiFi task may be delaying its execution) but prematurely is odd.

ESP_Sprite wrote: ↑

Thu Mar 30, 2023 6:43 am

How do you figure the timer callback is being called back *prematurely*? I could explain the callback being *late* (as a higher-priority WiFi task may be delaying its execution) but prematurely is odd.

Hi, I found this was happening by placing a log print in the timer handler. It fires exactly when it should if I don't start the WiFi task, but if I start the WiFi task, it will often (not always!) fire at completely the incorrect time (before it is supposed to). I'm talking like a few hundred ms after timer is set for 5000ms, etc. From the print statement inside the timer handler, I see this is always happening immediately following the wifi task's internal execution log statement I mentioned in the post.

Given that Espressif has the internal wifi task closed off to us, there is no way I can see for me to debug further. I can only speculate that maybe on wifi startup, they are doing something with the hardware timer that is also used for RTOS xTimer, causing an interrupt to fire. But I find it hard to believe such an egregious bug exists at this point.

The workaround I went with is to use the ESP Timer API instead of FreeRTOS's. But I would still like to know if there could be something I overlooked.

Nope, I agree, that is weird. Would you be able to provide us with a whittled down project that exhibits this behaviour? If so, I can have our WiFi team look at it.

I feel that the problem is similar to him。
url=viewtopic.php?f=13&t=32886