Closed savenlid closed 1 year ago
i did change the partition table to retain the info there from the main projet i work on. Initially i merged the usb-code into my "project" but when it failed i had to try it stand-alone, but wanted to keep my partitions. Also changed the FLASH size to 8MB to match the devkit so the partitions would fit.
I have used a lot of your example code for wifi and mqtt, i2c, uart, gpio, ADC, etc, this is the first time i run into trouble.
***ERROR*** A stack overflow in task USB MSC has been detected.
Try increasing the MSC class driver's task stack size in this line. Maybe something like...
.stack_size = 8192,
Hi
I already tried the stack increase, 4096 and 8192, did not help, both for the task-creation and also for the app itself.
I also tried to increase the timers according to another ticket. I also replaced my home-made usb cable with "normal" OTG-cable, same result. I had to short the vbus and vbusb signals on the devitc to get power from the uart-usb port ( provided from laptop )
Only things I can think of that differs from plan-vanilla-github is that i have a custom partioning, and changed the lash size to 8MB to match the devkit size.
Regardless, this "bug" has been observed historically by other people but has not been fully examined due to other reporters were not able to sumbit usb-communication-logs.
I will investigate if I can get hold of an usb-analyzer.
@savenlid Could you enable GDB stub on panic (via the CONFIG_ESP_SYSTEM_PANIC
) and have a poke around the overflowed task's TCB (in particular the pxTopOfStack
member).
I will as soon, as I find some time, also my saleae analyzer claims to do USB, so I will try to hook it up also.
Using the saleae did not gain anything useful.
I am in the gdb but I will have to google gdb commands, to finf the information you want.
A question. I once did "idf.py dfu-flash" Could that be the problem ? I did erase-flash afterwards, but I don't now 100% how things are used.
The crashing thread was thread 8 so i selected that one.
(gdb) info threads Id Target Id Frame
(gdb) print pxCurrentTCB $6 = (TCB_t volatile) 0x3fc9ef00
(gdb) print pxCurrentTCB $11 = {0x3fc9ef00, 0x3fc9bc00
(gdb) p pxCurrentTCB.pxTopOfStack $12 = (volatile StackType_t *) 0x3fc9ec10 "����n7@����Y\005@0\r\006"
p pxCurrentTCB->pxStack $14 = (StackType_t *) 0x3fc9e6fc "����������������#\t\006"
(gdb) x/49wx 0x3fc9ec10 0x3fc9ec10: 0x40376ed8 0x400559e0 0x00060d30 0x8037c712 0x3fc9ec20: 0x3fc9ecd0 0x00060d23 0x00000000 0x00060d20 0x3fc9ec30: 0x000004e5 0xb33fffff 0xb33fffff 0x80378169 0x3fc9ec40: 0x3fc9eca0 0x3fc95490 0x00000002 0x00000000 0x3fc9ec50: 0x00060d23 0xb33fffff 0xb33fffff 0x00000004 0x3fc9ec60: 0x820096c8 0x3fc9eca0 0x400556d5 0x400556e5 0x3fc9ec70: 0xfffffffd 0x40377205 0x00060d23 0x4037c79e 0x3fc9ec80: 0x3fc8f0cc 0x00000000 0x00000000 0x00000000 0x3fc9ec90: 0xb33fffff 0x00000000 0x00000000 0x00000000 0x3fc9eca0: 0x00000000 0x3fc9ecb0 0x0000000c 0x3fc9ed40 0x3fc9ecb0: 0x00060d23 0xa5a5a5a5 0xa5a5a5a5 0x00003253 0x3fc9ecc0: 0x8037a49d 0x3fc9ece0 0x3fc95488 0xffffffff 0x3fc9ecd0: 0x8200ff4c
// I am not good at gdb command-line usage
(gdb) info all-registers
pc 0x40375939 0x40375939 <panic_abort+21>
ar0 0x80379bd8 -2143839272
ar1 0x3fc9eb30 1070197552
ar2 0x3fc9eb7c 1070197628
ar3 0x3fc9ebbb 1070197691
ar4 0x3fc9ed90 1070198160
ar5 0x3fc9ed70 1070198128
ar6 0x3fc95c88 1070161032
ar7 0x0 0
ar8 0x0 0
ar9 0x1 1
ar10 0x1 1
ar11 0x0 0
ar12 0x3fc9ed70 1070198128
ar13 0x3fc9ed40 1070198080
ar14 0x3fc9e5b4 1070196148
ar15 0xffffffff -1
ar16 0xdeadbeef -559038737
ar17 0xdeadbeef -559038737
ar18 0xdeadbeef -559038737
ar19 0xdeadbeef -559038737
ar20 0xdeadbeef -559038737
ar21 0xdeadbeef -559038737
ar22 0xdeadbeef -559038737
ar23 0xdeadbeef -559038737
ar24 0xdeadbeef -559038737
ar25 0xdeadbeef -559038737
ar26 0xdeadbeef -559038737
ar27 0xdeadbeef -559038737
ar28 0xdeadbeef -559038737
ar29 0xdeadbeef -559038737
ar30 0xdeadbeef -559038737
ar31 0xdeadbeef -559038737
ar32 0xdeadbeef -559038737
ar33 0xdeadbeef -559038737
ar34 0xdeadbeef -559038737
ar35 0xdeadbeef -559038737
ar36 0xdeadbeef -559038737
ar37 0xdeadbeef -559038737
ar38 0xdeadbeef -559038737
ar39 0xdeadbeef -559038737
ar40 0xdeadbeef -559038737
ar41 0xdeadbeef -559038737
ar42 0xdeadbeef -559038737
ar43 0xdeadbeef -559038737
ar44 0xdeadbeef -559038737
ar45 0xdeadbeef -559038737
ar46 0xdeadbeef -559038737
ar47 0xdeadbeef -559038737
ar48 0xdeadbeef -559038737
ar49 0xdeadbeef -559038737
ar50 0xdeadbeef -559038737
ar51 0xdeadbeef -559038737
ar52 0xdeadbeef -559038737
ar53 0xdeadbeef -559038737
ar54 0xdeadbeef -559038737
ar55 0xdeadbeef -559038737
ar56 0xdeadbeef -559038737
ar57 0xdeadbeef -559038737
ar58 0xdeadbeef -559038737
ar59 0xdeadbeef -559038737
ar60 0xdeadbeef -559038737
ar61 0xdeadbeef -559038737
ar62 0xdeadbeef -559038737
ar63 0xdeadbeef -559038737
lbeg 0x400570e8 1074098408
lend 0x400570f3 1074098419
lcount 0x0 0
sar 0x4 4
windowbase 0x0 0
windowstart 0x1 1
configid0 0xc2f0fffe 3270574078
configid1 0x23090f1f 587796255
ps 0x60023 393251
threadptr 0x0 0
br 0x0 0
scompare1 0x0 0
acclo 0x0 0
acchi 0x0 0
m0 0x0 0
m1 0x0 0
m2 0x0 0
m3 0x0 0
gpio_out 0x0 0
f0 0x0 0
f1 0x0 0
f2 0x0 0
f3 0x0 0
f4 0x0 0
f5 0x0 0
f6 0x0 0
f7 0x0 0
f8 0x0 0
f9 0x0 0
f10 0x0 0
f11 0x0 0
f12 0x0 0
f13 0x0 0
f14 0x0 0
f15 0x0 0
fcr 0x0 0
fsr 0x0 0
accx_0
I took a brand new pristine esp32-s3 devkit directly out of the box, and flashed down same image. Same fault. I will now remove my edited partitions to default as in the example and see if that helps.
I went back to plain vanilla partitions, it still crash.
Hi @savenlid ,
Thank you so much so such a full logs.
Meanwhile, can I ask you few questions, that will help us a little bit:
Thanks a lot, these answers will help us to reproduce the problem.
Hi, I tried 6pcs of different sticks, they all fails.
Some but not all was formated FAT ( not FAT32 ) But SW seems not to get to the point of examing the file-structure even.
I will buy another USB-OTG cable next week see if that helps, but I doubt it since I already tried 2 cables.
We could remote debug it over teams, if you want to have a look.
Thanks
Problem fixed: I used 5.1 example source code in a 5.2(master) environment. Taking the 5.2 example source code and it worked.
const msc_host_driver_config_t msc_config = {
.create_backround_task = true,
.task_priority = 5,
.stack_size = 4096,
.callback = msc_event_cb,
};
Stack size was 2048 in 5.1
@savenlid Could you please confirm that the problem was solved by increasing the task stack? In your previous comment, you said that it didn't help https://github.com/espressif/esp-idf/issues/12082#issuecomment-1680414185
there are 3 stack sizes in the example
One help, one does not help.
A friend also did a scratch install trying the latest greatest, did not work on 1st attempt, worked on 2nd attempt, I will ask him if he did anything between the attempts.
This my friend had to do to get it working:
Turned on GDBSTUB via GUI och and then it worked:
Following changes was made by GUI:
diff --git a/sdkconfig b/sdkconfig index 388b055..18684cd 100644 --- a/sdkconfig +++ b/sdkconfig @@ -621,6 +621,9 @@ CONFIG_ESP_EVENT_POST_FROM_IRAM_ISR=y #
# +CONFIG_ESP_GDBSTUB_ENABLED=y +CONFIG_ESP_GDBSTUB_SUPPORT_TASKS=y +CONFIG_ESP_GDBSTUB_MAX_TASKS=32
# @@ -842,9 +845,9 @@ CONFIG_ESP32S3_TRACEMEM_RESERVE_DRAM=0x0
-CONFIG_ESP_SYSTEM_PANIC_PRINT_REBOOT=y +# CONFIG_ESP_SYSTEM_PANIC_PRINT_REBOOT is not set
-# CONFIG_ESP_SYSTEM_PANIC_GDBSTUB is not set +CONFIG_ESP_SYSTEM_PANIC_GDBSTUB=y
CONFIG_ESP_SYSTEM_RTC_FAST_MEM_AS_HEAP_DEPCHECK=y CONFIG_ESP_SYSTEM_ALLOW_RTC_FAST_MEM_AS_HEAP=y @@ -1683,6 +1686,8 @@ CONFIG_ESP32_APPTRACE_LOCK_ENABLE=y
CONFIG_POST_EVENTS_FROM_ISR=y CONFIG_POST_EVENTS_FROM_IRAM_ISR=y +CONFIG_GDBSTUB_SUPPORT_TASKS=y +CONFIG_GDBSTUB_MAX_TASKS=32
CONFIG_ESP32S3_DEEP_SLEEP_WAKEUP_DELAY=2000
I cant help the strange formatting in the message above.
We suspect this to have helped
+CONFIG_GDBSTUB_SUPPORT_TASKS=y +CONFIG_GDBSTUB_MAX_TASKS=32
Fixed by https://github.com/espressif/esp-idf/commit/e6fde2e13e667281932effccb7324814b558075d
Feel free to reopen if the problem persists
Answers checklist.
IDF version.
v5.2-dev-2164-g3befd5fff7
Operating System used.
Windows
How did you build your project?
Command line with Make
If you are using Windows, please specify command line type.
CMD
Development Kit.
esp32-s3 devkitc
Power Supply used.
USB
What is the expected behavior?
Taking the USB MSC example out of the box, fails in a way already described elsewhere.
Then the issue-poster finally said it was a hardware issue, and it then worked.
But regardless bad soldering of D- or D+, crashing is not an option due to flaky D-/D+ wiring.
What is the actual behavior?
I (287) cpu_start: Chip rev: v0.1 I (292) heap_init: Initializing. RAM available for dynamic allocation: I (299) heap_init: At 3FC95260 len 000544B0 (337 KiB): DRAM I (305) heap_init: At 3FCE9710 len 00005724 (21 KiB): STACK/DRAM I (312) heap_init: At 3FCF0000 len 00008000 (32 KiB): DRAM I (318) heap_init: At 600FE010 len 00001FF0 (7 KiB): RTCRAM I (326) spi_flash: detected chip: generic I (329) spi_flash: flash io: dio I (333) sleep: Configure to isolate all GPIO pins in sleep state I (340) sleep: Enable automatic switching of GPIO sleep configuration I (347) app_start: Starting scheduler on CPU0 I (352) app_start: Starting scheduler on CPU1 I (352) main_task: Started on CPU0 I (362) main_task: Calling app_main() I (362) gpio: GPIO[10]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0 I (402) example: Waiting for USB stick to be connected I (812) example: MSC device connected
ERROR A stack overflow in task USB MSC has been detected.
Backtrace: 0x40375812:0x3fc9cd30 0x40379c09:0x3fc9cd50 0x4037c63e:0x3fc9cd70 0x4037b187:0x3fc9cdf0 0x4037c74c:0x3fc9ce10 0x4037c742:0x00000000 |<-CORRUPTED 0x40375812: panic_abort at C:/Espressif/frameworks/esp-idf-v5.1/components/esp_system/panic.c:452
0x40379c09: esp_system_abort at C:/Espressif/frameworks/esp-idf-v5.1/components/esp_system/port/esp_system_chip.c:84
0x4037c63e: vApplicationStackOverflowHook at C:/Espressif/frameworks/esp-idf-v5.1/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:581
0x4037b187: vTaskSwitchContext at C:/Espressif/frameworks/esp-idf-v5.1/components/freertos/FreeRTOS-Kernel/tasks.c:3729
0x4037c74c: _frxt_dispatch at C:/Espressif/frameworks/esp-idf-v5.1/components/freertos/FreeRTOS-Kernel/portable/xtensa/portasm.S:450
0x4037c742: _frxt_int_exit at C:/Espressif/frameworks/esp-idf-v5.1/components/freertos/FreeRTOS-Kernel/portable/xtensa/portasm.S:245
Steps to reproduce.
Just use last master, using a esp32-s3 devkitc compile the example USB MSC HOST (OTG) Connect a usb-memory-stick ( possibly with some connection problem on d-/d+ Crash
Debug Logs.
More Information.
I soldered the USB OTG cable on my own. I am a professional in soldering, but faults can happen. I will buy a USB-OTG cable and try, but still it should not crash.