esp_lvgl_port: Always having a mutex lock(task_init_mux) makes it impossible to restore task priority (BSP-739)

[ThunderDai]

Board

ESP32P4_EV_BOARD

Hardware Description

ESP32P4_EV_BOARD

IDE Name

VSCode

Operating System

linux

Description

When the priority of a task is higher than taskLVGL, the priority of the task will be temporarily increased. However, due to taskLVGL constantly obtaining task_init_mux, even if other mutex locks have been released, the priority of the task cannot be restored to its original state

Sketch

NONE

Other Steps to Reproduce

No response

I have checked existing issues, README.md and ESP32 Forum

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[github-actions]

Hi @ThunderDai! Please be aware that (1) the following suggestions are generated by a bot and haven't been fact-checked by Espressif Systems, (2) burning eFuses and enabling security features are irreversible operations and can damage your ESP32 device. We hope that this message will help you until an Espressif Engineer looks at your issue.

---

Thank you for your detailed report regarding the priority inheritance issue with esp_lvgl_port and the task_init_mux mutex on the ESP32-P4.

Background:
In FreeRTOS, mutexes implement a priority inheritance mechanism: if a high-priority task is blocked by a lower-priority task holding a mutex, the lower-priority task temporarily inherits the higher priority until it releases the mutex. If a task (such as the LVGL task) frequently or continuously holds a mutex (like task_init_mux), any task that was blocked on that mutex will not have its priority restored until the mutex is fully released. This can lead to the situation you described, where the high-priority task's priority is not restored as expected, even after other mutexes are released.

Relevant Information from Espressif Documentation:

• Mutexes in FreeRTOS use priority inheritance to avoid priority inversion, but the task holding the mutex must release it in a timely manner; otherwise, the high-priority task remains blocked and the low-priority task cannot return to its original priority. This is a known behavior of FreeRTOS mutexes and not specific to ESP32-P4 hardware or esp_lvgl_port implementation Creating a Mutex Semaphore.
• The LVGL port for ESP-IDF requires all LVGL API calls to be protected by a lock/unlock mechanism to ensure thread safety. This is typically done using a mutex, as shown in the documentation and example code LVGL API usage.
• If a mutex is held for extended periods or is frequently locked by a long-running task, it can cause the exact priority inheritance issue you described.

Potential Solutions / Workarounds:

• Review the design to ensure that the LVGL task (or any task holding task_init_mux) only locks the mutex for the minimum time necessary to perform critical operations, and releases it as soon as possible.
• If possible, refactor the code so that the mutex is not held across blocking or long-running operations.
• Consider whether the LVGL task can be run at a higher priority, or whether the locking strategy can be adjusted to reduce contention.

Summary:
The behavior you are observing is a direct result of how FreeRTOS mutexes and priority inheritance work. If the LVGL task is frequently or continuously holding task_init_mux, it will prevent the priority of other tasks from being restored until the mutex is released. This is not a bug in ESP-IDF or esp_lvgl_port, but rather a limitation of the current locking strategy. Optimizing the duration and frequency of mutex locking in your application should help mitigate this issue.

If you need further assistance or have a specific code example where this is problematic, please provide more details so we can help investigate further.

References:

• Creating a Mutex Semaphore
• LVGL API usage

[PetrESP]

Hello @ThunderDai and thank you for using our LVGL port.
I see that you have an issue with priority inheritance of the LVGL port task caused by task_init_mux mutex which your higher priority task is requesting to take.
My question is: why are you attempting to take this task_init_mux mutex? It is supposed to be local to the LVGL port and an application using the LVGL port should only use the lvgl_port_lock and lvgl_port_unlock which use the lvgl_mux mutex.