lvgl: Watch Dog Timeout in lv_task_handle for ESP IDF v4.3.0 onwards
Perform all steps below and tick them with [x]
- Check the related part of the Documentation
- Update lvgl to the latest version
- Reproduce the issue in a Simulator
Describe the bug
Have been using LVGL v7.7.1 with ESP IDF v4.1.1 successfully for many past releases. However when we updated our ESP32 IDF to v4.3.1 the application code will randomly (and frequently) hang in lv_task_handle followed by a wdt timeout. Backtrace from the hang leads right back to: lv_refr_vdb_flush(). Updated LVGL to v7.11.0, and problem still persist.
Full Backtrace log is as follows: Backtrace:0x4008DBDD:0x3FFBF550 0x400844F9:0x3FFBF570 0x40167B8C:0x3FFF0EE0 0x401680CB:0x3FFF0F50 0x4016867D:0x3FFF0FE0 0x401713DD:0x3FFF1030 0x401714E0:0x3FFF1050 0x400F7C36:0x3FFF1080 0x400E8887:0x3FFF10A0 0x400E3570:0x3FFF1160 0x400DF636:0x3FFF1270 0x400DF723:0x3FFF1290 0x4008dbdd: esp_crosscore_isr at /home/murtuza/esp/esp-idf/components/esp32/crosscore_int.c:77
0x400844f9: _xt_lowint1 at /home/murtuza/esp/esp-idf/components/freertos/port/xtensa/xtensa_vectors.S:1105
0x40167b8c: lv_refr_vdb_flush at /home/murtuza/esp/rj40-esp32-w2/rj40-esp32/build/…/components/lvgl/lvgl/src/lv_core/lv_refr.c:941
0x401680cb: lv_refr_area_part at /home/murtuza/esp/rj40-esp32-w2/rj40-esp32/build/…/components/lvgl/lvgl/src/lv_core/lv_refr.c:576
0x4016867d: lv_refr_area at /home/murtuza/esp/rj40-esp32-w2/rj40-esp32/build/…/components/lvgl/lvgl/src/lv_core/lv_refr.c:478 (inlined by) lv_refr_areas at /home/murtuza/esp/rj40-esp32-w2/rj40-esp32/build/…/components/lvgl/lvgl/src/lv_core/lv_refr.c:400 (inlined by) _lv_disp_refr_task at /home/murtuza/esp/rj40-esp32-w2/rj40-esp32/build/…/components/lvgl/lvgl/src/lv_core/lv_refr.c:199
0x401713dd: lv_task_exec at /home/murtuza/esp/rj40-esp32-w2/rj40-esp32/build/…/components/lvgl/lvgl/src/lv_misc/lv_task.c:386 (discriminator 1)
0x401714e0: lv_task_handler at /home/murtuza/esp/rj40-esp32-w2/rj40-esp32/build/…/components/lvgl/lvgl/src/lv_misc/lv_task.c:134
To Reproduce
Steps to reproduce:
- Start with ESP IDF v4.3.1
- LVGL v7.11.0
- Cycle through Create and Destroy of lv objects (text, containers, images).
Will eventually find the WDT backtrace to here:
if(disp_refr->driver.buffer->last_area && disp_refr->driver.buffer->last_part) vdb->flushing_last = 1;
else vdb->flushing_last = 0;
Expected behavior
I expected the WDT to not timeout. But here we are. Bumped up the WDT to max in menuconfig, and yet it still hangs. I understand this is a platform related problem to ESP32, so any help or useful information that i can provide on the ESP32 form would be helpful as well.
Screenshots or video
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 35 (19 by maintainers)
I’m amazed it even worked with DMA between the PSRAM and the screen. That’s another reason why we need some heap manager in ESP32 that’s linked with LVGL.
@murtuzaq Thanks for reporting back your finding and the solution. I’m glad the example port helped you!
Guys i solved my issue with Watch Dog Time out. I went back to review the lv_port_esp32 project and found a discrepancy between how it allocated buffer memory vs how i have been doing it all this time.
In my source file, i had allocated buf1 and buf2 to external memory like this:
lv_color_t* buf1 = malloc(DISP_BUF_SIZE * 2)where in menuconfig malloc was to use external memory for malloc’s greater then 2k.And in lv_port_esp32 example, buf1 and buf2 memory was allocated as:
lv_color_t* buf1 = heap_caps_malloc(DISP_BUF_SIZE * sizeof(lv_color_t), MALLOC_CAP_DMA);which used internal memory.Since that change, i have not wdt since.
Thank you everybody on this ticket for your considerable help and feedback. And a special Thank you to @C47D for the example port code that you have given to this community.
I think the same is true in v7.
With v8, I think you have to call
lv_disp_set_rotationon the return value oflv_disp_drv_register, as that is a properlv_disp_t *.It is interesting that this issue is not more widely replicated. i will do my best to tear down my application code so that all that is left is the lvgl code and the symptom on the esp32 platform. wish me luck.