esp_lvgl_port 2 with lvgl 9 - Crashing with simple UI elements (BSP-476)

[sukesh-ak]

I am working on a commercial project based on this sample which uses esp_lvgl_port 2.0 https://github.com/sukesh-ak/IDF5-ESP_LCD-LVGL9

I use Observer in lvgl 9 to bind and create API for the UI. I have used lv_msg in lvgl 8 for the same use case which is deprecated now. https://docs.lvgl.io/master/others/observer.html

I am seeing several issues which were not there in the past like StackOverflow and other exceptions, even with simple less complicated UI elements.

Sample crashing stack

I (5191) HMI-EVENTS: Set Temp: 39, current Temp: 1, Pump State: 1

assert failed: xQueueGenericSend queue.c:873 (!( ( pvItemToQueue == ((void *)0) ) && ( pxQueue->uxItemSize != ( UBaseType_t ) 0U ) ))

Backtrace: 0x40081e45:0x3ffdeea0 0x4008bd69:0x3ffdeec0 0x40092181:0x3ffdeee0 0x4008c156:0x3ffdf000 0x4008c376:0x3ffdf040 0x400dc301:0x3ffdf060 0x400dbe8f:0x3ffdf080 0x4008e501:0x3ffdf0b0
0x40081e45: panic_abort at C:/espressif/esp/esp-idf/components/esp_system/panic.c:452

0x4008bd69: esp_system_abort at C:/espressif/esp/esp-idf/components/esp_system/port/esp_system_chip.c:84

0x40092181: __assert_func at C:/espressif/esp/esp-idf/components/newlib/assert.c:81

0x4008c156: xQueueGenericSend at C:/espressif/esp/esp-idf/components/freertos/FreeRTOS-Kernel/queue.c:873 (discriminator 2)

0x4008c376: xQueueGiveMutexRecursive at C:/espressif/esp/esp-idf/components/freertos/FreeRTOS-Kernel/queue.c:737

0x400dc301: lvgl_port_unlock at D:/Dev/project/managed_components/espressif__esp_lvgl_port/src/lvgl9/esp_lvgl_port.c:139

0x400dbe8f: get_current_temp at D:/Dev/project/main/ext_events.c:79

0x4008e501: vPortTaskWrapper at C:/espressif/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:162

Its crashing where there is a line like below which updates the state (enable/disable) of a button. I didn't have to wrap these in lock/unlock earlier. Currently I have done that too and its still an issue.

lv_subject_set_int(&pump_state_subject, pump_state);

I believe the issue is coming from RecursiveMutex since I have another sample with lvgl 8 here which was using normal Mutex earlier without issues. Mutex Take/Leave was required only while showing a full screen unlike now. https://github.com/sukesh-ak/ESP32-TUX/blob/master/main/helpers/helper_display.hpp

So the question is, do we need RecursiveMutex in this scenario? Or is there a specific reason for using it? I don't want to skip esp_lv_port for now unless I am stuck without a way out.

[sukesh-ak]

My earlier sample was inspired by this code snippet

https://github.com/espressif/esp-iot-solution/blob/master/components/gui/lvgl_gui/lvgl_gui.c

[espzav]

Hi @sukesh-ak, We are using RecursiveMutex because sometimes there is some code called from some LVGL callback which is call another LVGL code and it hnags. You can use normal Mutex, but you should check where you call it and you cannot call it from LVGL callbacks.

[sukesh-ak]

Thanks for the response @espzav I will find some time to write a sample to test without esp_lvgl_port using only Mutex to see where/why its crashing. Will report back once I figure out a solution (if any).