-
Notifications
You must be signed in to change notification settings - Fork 7.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
wifi:trc.c rcReachRetryLimit 1741 (IDFGH-6267) #7936
Comments
commit:2e74914051 |
@achao1104 please decode the backtrace. |
Can I have your email? I can send you the elf file. |
D:\project\esp32\idf-v4.3.1>xtensa-esp32-elf-addr2line -pfiaC -e D:\project\esp32\temp\2021-11-19-wifidump\solardevice.elf 0x4002eade:0x3ffcd8e0 0x4002f259:0x3ffcd900 0x40038972:0x3ffcd920 0x40027357:0x3ffcd990 0x4002748d:0x3ffcd9c0 0x4002751a:0x3ffcd9e0 0x400f8af2:0x3ffcda10 0x400fbb25:0x3ffcdd20 0x40105c72:0x3ffcdd50 0x40034b4d:0x3ffcdd80 0x400c6ae1:0x3ffcddd0 0x400d950d:0x3ffcde40 0x400c86c6:0x3ffcde90 0x400cbf55:0x3ffcdeb0 0x400ccb6d:0x3ffcded0 0x400cbbae:0x3ffcdef0 0x400cd802:0x3ffcdf10 0x400c5d42:0x3ffcdf30 0x4002895d:0x3ffcdf60 0x4008abf7:0x3ffcdf80 0x400c3a13:0x3ffcdfa0 0x40027132:0x3ffcdfc0 0x400df6c9:0x3ffe3830 0x400db865:0x3ffe3860 0x400dbce5:0x3ffe38a0 0x400dbf47:0x3ffe38d0 0x4003a199:0x3ffe3910 |
it looks like something in your code might be blocking wifi from acquiring a semaphore lock while an ISR is running. I'd suggest reviewing what is going on in:
|
thanks for your reply, but not really. |
line 56 is: esp_restart(); |
since there are two cameras connected with the esp32s2, they might send too much traffic, so the wifi is blocking other task, just my guess. |
your call to esp_restart is blocking WiFi from printing a message (likely about shutdown) due to your ISR hook point blocking the UART ISR from locking itself etc. ISRs have very strict requirements as to what can/can not be done inside them. This looks like a case where you should be waking up another task to do the restart without blocking the ISR context. You can do this via xTaskNotifyFromISR or posting to a semaphore that a task is blocked on. |
D:\project\esp32\idf-v4.3.1>python D:\project\esp32\idf-v4.3.1\components\espcoredump\espcoredump.py info_corefile -t raw -c D:\project\esp32\temp\2021-11-19-wifidump\863949040975157-2021-11-19-17-32-40-0913277.dump D:\project\esp32\project\solardevice\build\solardevice.elf
|
thanks, I got your point. |
It has little to do with your current tasks being blocked or not. Your ISR is calling esp-idf/components/esp_system/esp_system.c Lines 78 to 99 in 098dfe8
Since you are calling this within an ISR context there are restrictions on acquiring semaphores as seen here: esp-idf/components/newlib/locks.c Lines 138 to 140 in 98d34e5
Which is triggering the abort from your backtrace. The solution I'd suggest is a light weight task that runs at a high priority that blocks on a semaphore OR uses |
sorry, I may not make it clear. I mean why the watch dog is triggered, I think it might be due to wifi is busy since it only happen when two cameras are connected.
…---Original---
From: "Mike ***@***.***>
Date: Fri, Nov 19, 2021 21:54 PM
To: ***@***.***>;
Cc: ***@***.******@***.***>;
Subject: Re: [espressif/esp-idf] wifi:trc.c rcReachRetryLimit 1741 (IDFGH-6267) (Issue #7936)
It has little to do with your current tasks being blocked or not. Your ISR is calling esp_restart() which will suspend all tasks:
https://github.com/espressif/esp-idf/blob/098dfe8a08e21d5ba95cb1ec8558d1531158267b/components/esp_system/esp_system.c#L78-L99
Since you are calling this within an ISR context there are restrictions on acquiring semaphores as seen here:
https://github.com/espressif/esp-idf/blob/98d34e5f6db8904c31bd1e372d9896e4931d7a9b/components/newlib/locks.c#L138-L140
Which is triggering the abort from your backtrace. The solution I'd suggest is a light weight task that runs at a high priority that blocks on a semaphore OR uses ulTaskNotifyTake to wait for wake up from the ISR callback context you are using. Inside that task you can safely call esp_restart() and not have the esp32 crash and restart.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
|
I can't answer why your ISR is being called as you haven't shared how you connected it to the rest of FreeRTOS callbacks. But I CAN tell you why it crashed and it is not a watchdog crash. It is crashing due to your code calling |
thanks, I understand your point. I use pppos sample+wifi ap mode+nat. it can run well except I let two cameras connect esp32.
…---Original---
From: "Mike ***@***.***>
Date: Fri, Nov 19, 2021 22:14 PM
To: ***@***.***>;
Cc: ***@***.******@***.***>;
Subject: Re: [espressif/esp-idf] wifi:trc.c rcReachRetryLimit 1741(IDFGH-6267) (Issue #7936)
I can't answer why your ISR is being called as you haven't shared how you connected it to the rest of FreeRTOS callbacks.
But I CAN tell you why it crashed and it is not a watchdog crash. It is crashing due to your code calling esp_restart() within an ISR context which prevents all other calls from acquiring their semaphores since the code being called is not expected to be called from within an ISR context.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
|
hi @atanisoft I have a question. Why does wifi call esp_restart in your project? |
when there is a problem, the device will restart itself. |
Hello, I used blow codes before to restart device once task wdt is triggered, we found some times 'wifi' task will be always busy to trigger the task wdt, but once esp_task_wdt_isr_user_handler called esp_restart(), it will cause another panic due to ungracefully shutdown of the wifi. void esp_task_wdt_isr_user_handler(void) E (1753869) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time: Backtrace:0x400C3CD6:0x3FFCDFA0 0x40027132:0x3FFCDFC0 0x400DF8ED:0x3FFE0D60 0x400DBA89:0x3FFE0D90 0x400DBF09:0x3FFE0DD0 0x400DC05F:0x3FFE0E00 0x400DC17B:0x3FFE0E30 0x4003A199:0x3FFE0E70 0x40027132: _xt_lowint1 at D:/project/esp32/idf-v4.3.1/components/freertos/port/xtensa/xtensa_vectors.S:1105 0x400df8ed: rcUpdatePhyMode at ??:? 0x400dba89: ic_set_trc at ??:? 0x400dbf09: lmacInit at ??:? 0x400dc05f: lmac_record_txtime at ??:? 0x400dc17b: lmacRetryTxFrame at ??:? 0x4003a199: ppResortTxAMPDU at ??:? |
hi @achao1104 I see your backtrace contains the operation of adc. In your project, can you shield the function of adc, test WIFI separately, and eliminate the interference of other modules on WIFI |
@achao1104 can you try latest v4.3? since we fix a bug that ADC impact Wi-Fi recently. |
As suggested in previous post, let us track in #7897 |
idf4.3.1, we connect two cameras with esp32s2 and keep it running, after a couple of hours, it will crash as below.
E (187517575) wifi:sched is null, if=0 tid=0 flags=0
E (187517575) wifi:trc.c rcReachRetryLimit 1741
E (187522565) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (187522565) task_wdt: - IDLE (CPU 0)
E (187522565) task_wdt: Tasks currently running:
E (187522565) task_wdt: CPU 0: wifi
abort() was called at PC 0x40027357 on core 0
Backtrace:0x4002eade:0x3ffcd8e0 0x4002f259:0x3ffcd900 0x40038972:0x3ffcd920 0x40027357:0x3ffcd990 0x4002748d:0x3ffcd9c0 0x4002751a:0x3ffcd9e0 0x400f8af2:0x3ffcda10 0x400fbb25:0x3ffcdd20 0x40105c72:0x3ffcdd50 0x40034b4d:0x3ffcdd80 0x400c6ae1:0x3ffcddd0 0x400d950d:0x3ffcde40 0x400c86c6:0x3ffcde90 0x400cbf55:0x3ffcdeb0 0x400ccb6d:0x3ffcded0 0x400cbbae:0x3ffcdef0 0x400cd802:0x3ffcdf10 0x400c5d42:0x3ffcdf30 0x4002895d:0x3ffcdf60 0x4008abf7:0x3ffcdf80 0x400c3a13:0x3ffcdfa0 0x40027132:0x3ffcdfc0 0x400df6c9:0x3ffe3830 0x400db865:0x3ffe3860 0x400dbce5:0x3ffe38a0 0x400dbf47:0x3ffe38d0 0x4003a199:0x3ffe3910
ELF file SHA256: b017d89a7614548a
The text was updated successfully, but these errors were encountered: