LVGL Watchdog Issue with Dynamic Menu List and TileView

MCU: ESP32S3
LVGL from esp_lvgl_port v2.6.1 (9.2 I think)
ESP-IDF: v5.4

Hello everyone,

I’m working on a fairly complex GUI composed of many screens and nested elements.

Specifically, I’m having trouble creating a menu list with multiple submenus. For example:

  • A >
    – AA >
    – AAA
    – AAB
    – AAC
    – AAD
    – AB >
    – AC >
  • B >
    – BA >
    – BB >
  • C >
  • Z >

Each list contains dozens of items across different levels.

Initially, I was initializing the entire screen at load time, but I encountered strange behavior with LVGL: when switching to the screen containing the menu list, the LVGL task would get stuck, and I’d see a watchdog trigger caused by some lv_* functions.

To address this, I changed my approach to load each screen dynamically upon click. I used a tileview, assigning one tile per menu item. Each tile was initialized empty and filled later.

This worked for a while, but as the implementation grew, the watchdog issue reappeared.

I’ve already increased the LVGL task stack size and adjusted various memory-related parameters in sdkconfig, but the issue persists.

My new idea is to create a maximum of n tiles, where n is the maximum depth of the menu/submenu structure, and load each element dynamically on click to further reduce memory usage.

However, even with this approach, I’m still encountering the same watchdog problem.

Has anyone experienced something similar or found a reliable solution? Any hints or suggestions would be greatly appreciated.

Thank you in advance!

If you have many subMenus, you cannot create all subMenus at the same time.
When opening a submenu, you must create only it and its objects, and have everything deleted.

Possibly, for the test, you need to increase the amount of RAM allocated to LVGL, within lv_conf.h, increase the definition of LV_MEM_SIZE

Hi Stipa889,

thanks for your answer.
That was exactly what I was doing.
The problem is that it probably cannot manage a lot of empty tiles.
I will try by changing the memory amount, and I will let you know.
But you know why we are having a watchdog timer error, instead of a memory error?

Hi.

Give me the LOG message when the error occurred…

Hey, sorry for the delay in the answer.
Here is the log:

Initialized menu configuration table with 24 entries
E (7511) task_wdt: Task watchdog got triggered. The following tasks/users did not reset the watchdog in time:
E (7511) task_wdt:  - IDLE0 (CPU 0)
E (7511) task_wdt: Tasks currently running:
E (7511) task_wdt: CPU 0: gui_task
E (7511) task_wdt: CPU 1: IDLE1
E (7511) task_wdt: Print CPU 0 (current core) backtrace


Backtrace: 0x42055F82:0x3FC9A870 0x42056398:0x3FC9A890 0x40377955:0x3FC9A8C0 0x4206B4AC:0x3FCE6770 0x4201FE2A:0x3FCE6790 0x42011D96:0x3FCE67D0 0x420125B4:0x3FCE6850 0x4200F282:0x3FCE6890 0x4200D6D7:0x3FCE68C0 0x4037EB95:0x3FCE6910
--- 0x42055f82: task_wdt_timeout_handling at /Users/andrea/esp/v5.4.2/esp-idf/components/esp_system/task_wdt/task_wdt.c:434
--- 0x42056398: task_wdt_isr at /Users/andrea/esp/v5.4.2/esp-idf/components/esp_system/task_wdt/task_wdt.c:507
--- 0x40377955: _xt_lowint1 at /Users/andrea/esp/v5.4.2/esp-idf/components/xtensa/xtensa_vectors.S:1240
--- 0x4206b4ac: lv_assert_handler at /Users/andrea/git/spr-esp32/components/middleware/graphic_lib/lvgl/src/misc/lv_assert.c:37
--- 0x4201fe2a: lv_obj_align_to at /Users/andrea/git/spr-esp32/components/middleware/graphic_lib/lvgl/src/core/lv_obj_pos.c:330
--- 0x42011d96: list_screen_init at /Users/andrea/git/spr-esp32/components/application/spGraphics/setup_scr_list_menu.c:1029
--- 0x420125b4: spGUI_setup_main_list at /Users/andrea/git/spr-esp32/components/application/spGraphics/setup_scr_list_menu.c:697
--- 0x4200f282: spGUI_setup_main at /Users/andrea/git/spr-esp32/components/application/spGraphics/setup_scr_main.c:54
--- 0x4200d6d7: gui_task at /Users/andrea/git/spr-esp32/components/application/spTasks/taskGUI.c:185
--- 0x4037eb95: vPortTaskWrapper at /Users/andrea/esp/v5.4.2/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:139