tore-espressif
commented
10 months ago hi @TRYOKETHEPEN , thanks for the issue and log.
So far, the only case when we saw usb_host_install failing is because of failed interrupt allocation. Symptoms of your problem are the same. Here's a very good explanation of what is going on and how to debug it, from one of our colleagues https://github.com/espressif/esp-idf/issues/10903#issuecomment-1456176716
TLDR:
When USB_HOST is set at CPU1, the project running well.
The easiest solution for you is to pin the USB task to CPU1
acautomacaoecontrole
Answers checklist.
IDF version.
v5.1.1
Espressif SoC revision.
ESP32-S3
Operating System used.
Windows
How did you build your project?
VS Code IDE
If you are using Windows, please specify command line type.
None
Development Kit.
ESP32-S3-DevKitC-1 v1.1
Power Supply used.
USB
What is the expected behavior?
My project create 3 freeRTOS tasks at app_main(): [task1] RC522 scann rf-id. [task2] LCD display & touch, with LVGL. [task3] USB_HOST, which calls usb_host_install() that triggers this abortion.
My project file: project1.zip task1 code based on https://github.com/abobija/esp-idf-rc522. task2 code based on "spi_lcd_touch" example. task3 code based on "hid" example.
When I build&flash&monitor, the expected monitor log should be: _2023-11-14 14:04:32 I (902) main_task: Started on CPU0 2023-11-14 14:04:32 I (912) main_task: Calling app_main() 2023-11-14 14:04:32 W (912) 主程序: >>>开启RC522读卡任务(异步) 2023-11-14 14:04:32 I (922) rc522: versionReg: 0xb2 2023-11-14 14:04:32 I (922) rc522: Initialized (firmware v2.0) 2023-11-14 14:04:32 W (932) 主程序: >>>开启LCD 2023-11-14 14:04:32 I (932) lcd_touch_lvgl_init: 初始化SPI 2023-11-14 14:04:32 I (942) lcd_touch_lvgl_init: 初始化LCD panel 2023-11-14 14:04:32 I (942) gpio: GPIO[4]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 2023-11-14 14:04:32 I (952) lcd_touch_lvgl_init: 安装panel驱动:ILI9341
2023-11-14 14:04:32 I (962) gpio: GPIO[6]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 2023-11-14 14:04:32 I (1092) lcd_touch_lvgl_init: 初始化LCD触控panel 2023-11-14 14:04:32 I (1092) lcd_touch_lvgl_init: 安装panel驱动:XPT2046
2023-11-14 14:04:32 I (1092) lcd_touch_lvgl_init: 初始化LVGL绘制缓冲区
2023-11-14 14:04:32 I (1092) lcd_touch_lvgl_init: 初始化&注册LVGL显示驱动器 2023-11-14 14:04:32 I (1102) lcd_touch_lvgl_init: 初始化LVGL定时器 2023-11-14 14:04:32 I (1112) lcd_touch_lvgl_init: 初始化LVGL触控驱动器
2023-11-14 14:04:32 W (1112) 主程序: >>>开启USB HOST HID 2023-11-14 14:04:32 I (1122) usb_hid: 安装USB HOST驱动 2023-11-14 14:04:32 I (1122) usb_hid: 执行任务usb_events 2023-11-14 14:04:32 I (1162) usb_hid: 安装USB HOST驱动成功 2023-11-14 14:04:32 I (1162) usb_hid: 安装HID驱动 2023-11-14 14:04:32 I (1162) usb_hid: 创建HID任务 2023-11-14 14:04:32 I (1162) usb_hid: 执行任务hidtask
What is the actual behavior?
If I create USB_HOST task at CPU0, it panics like the 【error log】.
Then I tried different combinations(I don't know how to change the CPU where the LVGL task created, it seems always running at CPU0):
When USB_HOST is set at CPU1, the project running well. When USB_HOST is set at CPU0 or NO_AFFINITY, the project aborts at usb_host_install(), unless one of the taks1&taks2 is cancelled. _I say "cancelled", what actually I did: [cancel task1]: Annotate "rfid_start_scann();" at app_main(). [cancel task2]: Annotate "lcd_touch_lvgl_start();" at appmain().
I don't know why USB_HOST task running at CPU0 is complict with other tasks, could it be because of stack overflow?
Steps to reproduce.
\
Debug Logs.
More Information.
No response