WiFi disconnect and lockup in "wifi" task. (IDFGH-14) #2370
Comments
|
Yes, this issues always exist until the newest IDF. I tested it just now, it still happened again. In my case, I use Bluetooth and wifi coexist and enable the coexist item in the menuconfig option. following is my looping log: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
any suggestion or point out the problem is appreciated. |
|
Facing same issue after updating my esp-idf version from release/v3.0 (commit id : 0e640c61bd10ac848fc7114199fc7b30381b5332) to release/v3.1 (commit id : d91c425178d4e37b72178c231b5cc50b7ab157e2). With earlier version 3.0, didn't faced this issue. Its looping with below log, until I reset the board.
Thanks, |
FayeY
changed the title
|
Is there any updates on this thread? |
|
I hit this problem today when i updated from 3.0 to 3.1 as well Currently my workaround is to set the power management to
and setting the listen value very very low. I tried just using power save none (and the default MIN option) but neither of those seemed to properly solve the issue. EDIT: woops spoke too soon, i'm still seeing this problem sometimes, but the above settings seem to help a little bit (it doesn't go right into WDT mode on boot) |
|
I've been trying to change my settings to more closely match the example https://github.com/espressif/esp-idf/blob/release/v3.1/examples/wifi/power_save/sdkconfig.defaults to see if any of those options fixed it (i figure, the examples can't be exhibiting this or it would have been fixed earlier right?) I've been running for about an hour now (longer than ever before) after changing my CPU to 80mhz obviously this is less than ideal, but hopefully this helps the espressif devs figure out what's going on. @NOA-Vernon @vonnieda @vbvchauthmal if you change your CPU to: CONFIG_ESP32_DEFAULT_CPU_FREQ_80=y does this problem still occur? (mine was at CONFIG_ESP32_DEFAULT_CPU_FREQ_160 by default) |
|
@sebirdman Yes, that did not happen again in 2 hours after I changed the CPU to 80 MHz, But the I2S output seems not fast enough after changed and the sound sounded not clear. why 80 MHz runs normally and that problems always occurred while CPU runs at 160MHz and 240MHz? |
|
@NOA-Vernon Sounds like your application needs the cpu to be higher than 80MHz. I'm not sure exactly why this bug isn't happening at 80MHz (since the code isn't readily available for the wifi part of the esp32) however, I can speculate (this might be very wrong...): When running a FreeRTOS task, you have to yield to other tasks occasionally with something like:
without this, the WatchDog timeout will trigger and you'll get a message like: You can actually cause this output yourself, setup a FreeRTOS task with a loop and don't do any kind of vTaskDelay and you'll get something like: I suspect that this doesn't happen at 80MHz because whatever the delay that exists in the wifi task is optimized for that cpu speed, and at higher speeds it's not yielding enough. EDIT: As a hack, we could maybe put a shim in between the vTaskDelay that gets passed to the wifi driver, figure out what that vTaskDelay values are, and modify them to 'fix' this: esp-idf/components/esp32/wifi_os_adapter.c Line 439 in aaf1239 EDIT 2: As another potential workaround, you could try increasing CONFIG_TASK_WDT_TIMEOUT_S instead of altering the CPU speed. Maybe the wifi task just sometimes takes longer to reset the watchdog? |
|
@sebirdman tha maximum value of CONFIG_TASK_WDT_TIMEOUT_S tent to be 30 seconds, I attemp to increase this timeout to 60 secnods, but it does't work and the interval of print out the wdt timeout log is 30 seconds, the watchdog got triggered always even whaterver the value of CONFIG_TASK_WDT_TIMEOUT_S to be set. Task watchdog got triggered. The following tasks did not reset the watchdog in time:[2018-09-14 11:05:35.078]
|
|
@NOA-Vernon drat, i think we will have to wait for espressif to respond with a real fix then. edit: oh maybe there is one already. the latest (not included in v3.1 release) wifi blobs have this commit: espressif/esp32-wifi-lib@4b0f2d2 i'll update this lib to the latest on my esp-idf and report back edit2: nope, that doesn't help |
|
Hi @NOA-Vernon @vonnieda @sebirdman, we do have the "Task WDT" issue in WiFi/BT coexist and our engineers now are debugging this issue with highest priority . I'm not sure whether your "Task WDT" issue is same as the one we are investigating. Could you help to check the backtrace:
|
|
Hi @liuzfesp , just do the steps you provided above and the unexpected event occurred again, following is the log regarding "Task WDT" issue. Task watchdog got triggered. The following tasks did not reset the watchdog in time:
Backtrace: 0x400955a0:0x3ffc05b0 0x40095777:0x3ffc05d0 0x400d3483:0x3ffc05f0 0x40082731:0x3ffc0610 0x4008ee3e:0x00000000 Rebooting... rst:0xc (SW_CPU_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT) |
|
Hello
I can provide "сoredump". Can this help you? |
|
This is my coredump from the terminal |
|
Hi @liuzfesp,
Do you have any news on this issue? I'm facing this issue even if only WiFi is enable (ble not used) Can you confirm if this problem is occuring only on esp-idf v3.1? Thanks |
|
@PegasYura @davctv @NOA-Vernon I think your issues are same as the one we are debugging. @TianHao-Espressif now is debugging it. |
|
@liuzfesp @TianHao-Espressif Same issue here. Any updates? |
|
I'm facing the same issue, it's a roadblock for me. Really looking forward to any progress on this! |
|
Hello, is there any news? |
|
@liuzfesp @TianHao-Espressif any update or workaround besides clocking to 80Mhz? This is very critical to our application. |
|
I'am getting the same coredump as @PegasYura. I'am also on IDF version 3.1. |
|
related to #2489 It's resolved. |
|
I just tested it with lattest ESP-IDF commit. I keep getting: W (34833) EM: STA DISCONNECTED In loop, it just can't connect to the WiFi. And with older version of ESP-IDF same source code connect successfully. |
|
@MIlan991 , do you use BLE or BR/EDR while wifi is connecting? |
|
@TianHao-Espressif I'm using BLE. |
|
Is there any update on this? Same source code is working fine with older version of ESP-IDF. |
|
Any update? |
|
We've run into the same issue while running on Here's a log that shows the behavior after the WiFi network is dropped: The last line in that log represents a call to At this point, every 5 seconds the watchdog is triggered. We've updated the IDF to It's a very rare bug, and we can't seem to force its behavior. Any information on the root cause? Are there any confirmed work-arounds? |
|
HI @NateBowen for latest IDF v3.1/3.2/3.3, the watchdog issue in WiFi/BT coexist should have been fixed. For old v3.0-rc, could you help to check the backtrace:
|
|
@liuzfesp Thank you for getting back so quickly. I'm confused why this would be a WiFi/BT coexist bug when we haven't enabled Bluetooth in the sdkconfig? |
|
Hi @NateBowen, I think it's not easy for us to analyze the watchdog log without backtrace. Moreover v3.0-rc1 is a very old release, suggest your to upgrade your IDF to latest v3.0 (3.0.7 or 3.0.8), or to v3.1/3.2. |
|
To add to what @liuzfesp has said, you can get the task watchdog to trigger a restart (printing the backtrace) if you enable CONFIG_TASK_WDT_PANIC. Updating IDF to v3.1.3 might also help. |
|
@liuzfesp I understand the backtrace issue, and I wish I had that information for you. However, I mentioned in my last post that this is happening on |
|
@igrr Is there a known lockup issue in |
|
HI @NateBowen 54ef8ed still too old for the interrupt watchdog issue, you can update to latest v3.1 (not v3.1.3) to check whether it breaks connection to mobile app. |
|
Hi @liuzfesp. I've been able update to |
projectgus
changed the title
|
@vonnieda @NateBowen Hi, has your issue been resolved? Could you help share if any updates for this issue? Thanks. |
|
Hi @Alvin1Zhang. We haven't seen any issues since my last comment. Thank you. |
|
@Alvin1Zhang I just saw this again yesterday, for the first time in months. Here is what I saw in the logs: The wifi task never recovered and I had to restart the device. |
|
HI @vonnieda, We also saw similar watchdog in our recently release test, but unfortunately we didn't enable that watchdog panic and didn't get the backtrace. We are now reproducing this issue. Will update you once fixing it. |
|
Glad to hear it, thank you! |
|
Hi, Here is log: |
|
Hi @chegewara, could you help to provide following info:
|
|
Hi, I can provide test code, but it requires to use sipeed maixduino board and this code on esp32: |
|
is there an update in this? I have the same problem |
|
Still having this issue on the latest release. A workaround is using |
|
@Octogonapus do you mean still have the task watchdog issue on latest master? |
Not on the latest master. I am using v3.3.0. |
|
Hi @Octogonapus does your v3.3 IDF contains fix: 2d5ee43, this commit fix a bug that WiFi stop leads to watchdog. For other releases, the fix commits are: |
|
I don't think I can check that because I am using PlatformIO, so there is no git repo on disk I can look in. I compared the crc32 hashes of a few of those binaries, though; they are different. |
|
@Octogonapus that's OK. What I suggest is:
|
|
Hi @Octogonapus, any update about this issue? |
|
@Alvin1Zhang I have not seen this issue in quite some time, so I suspect it was resolved by updating to v3.3.1 at some point. |
|
Thanks for the updates. Would close the ticket for now, feel free to reopen the issue if it happens again. Thanks. |
|
I'm seeing similar issues on ESP-IDF v3.3-r4 via Mongoose-os. My device connects fine, but after some time (usually 1-3 hours) it gets stuck into a disconnect loop. I'm not seeing the watchdog timeout but the device disconnects with the same logging shown above, then reconnects, gets an IP address but then a few seconds later disconnects again with the same error. Here is a log extract: `sleep.js:7 Setting auto sleep mode init.js:504 NETWORK: "GOT_IP" I (52375) wifi: new:<7,0>, old:<7,0>, ap:<255,255>, sta:<7,0>, prof:1 mgos_wifi.c:136 WiFi STA: Connected, BSSID c4:41:1e:67:69:24 ch 7 RSSI -87 init.js:504 NETWORK: "GOT_IP" I (62005) wifi: new:<7,0>, old:<7,0>, ap:<255,255>, sta:<7,0>, prof:1 |
Environment
Problem Description
Board suddenly disconnected from WiFi and the "wifi" task consumed all CPU, requiring a power cycle.
The above watchdog messages just continued for several minutes until I power cycled the board.
This is the first time that I've seen this issue, but there have been a handful of instances of the device locking up previously, so I do wonder if this could be related.
At the time that the code emitted the message "WiFi connecting to "xx"" it would have been calling esp_wifi_connect().
Thanks,
Jason
The text was updated successfully, but these errors were encountered: