LVGL Widgets Demo stopped working in v4.1 on mimxrt1060_evk@A

[laodzu]

Describe the bug

The demo stopped working in v4.1 on my mimxrt1060_evk@A board. In the new version I only get half a screen of random coloured pixels instead of the actual UI.

git bisecting yielded this commit as the culprit:

 commit 54472522477bccf3dd4a17d913c0116ee7e318d8
Author: Fabian Blatz <fabianblatz@gmail.com>
Date:   Sun Jan 26 18:53:26 2025 +0100

    west.yml: Sync LVGL module to 9.2.x
    
    Update the west yaml to point to the new LVGL version.
    
    Signed-off-by: Fabian Blatz <fabianblatz@gmail.com>

 west.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

This is already the second time that git bisect is not useful with LVGL problems because of this setup. 😭

This commit updates the LVGL repo from v9.2.0-346-g6decbb7f7 to v9.2.0-455-g1ed1ddd88. I skimmed the somewhat large diff but did not see an immediate culprit. Does anyone have an idea where I could start looking?

Regression

• This is a regression.

Steps to reproduce

west build -p -b mimxrt1060_evk@A/mimxrt1062/qspi --shield rk043fn02h_ct
samples/modules/lvgl/demos -- -DCONFIG_LV_Z_DEMO_WIDGETS=y

Relevant log output

Impact

Major – Severely degrades functionality; workaround is difficult or unavailable.

Environment

OS is Linux, Zephyr SDK 0.16.8

Additional Context

No response

[github-actions]

Hi @laodzu! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[JarmouniA]

Does the display sample work?

[hakehuang]

Does the display sample work?

the display sample works on this board on v4.2.0-1706-g12a866f7d3f.

west build -b mimxrt1060_evk@C/mimxrt1062/qspi -p always --shield=rk043fn02h_ct

so we need enhance it by #84456

[laodzu]

Even though it is difficult to debug, I could make some progress here. In the meantime I believe we are - again - running out of memory somewhere and then as a result the whole program fails. I get to this conclusion by the following reasoning:

Looking into the working version, I realized that the display half full of random data is always there after running mcux_elcdif_init. Only in the good case this will be overwritten with the proper LVGL content. In the bad case this never happens and so the display ends up with this pattern. Potentially I think the display should be properly erased in the initialization phase, but currently this is not important.

The update of the display is triggered by the flush_thread in LVGL. I can put a break point on lvgl_display.c:31 to see this. In the good version this breakpoint is reached and on continuing the display refreshes normally. In the bad case, this breakpoint is never reached, and the system ends up in k_sys_fatal_error_handler as it crashed.

I encountered a memory related problem in this demo (#85306) before, so maybe this is similar again.

[laodzu]

Does the display sample work?

Yes, this demo works just fine. As said in my other comment, I believe this bug is triggered by memory exhaustion rather than a regression in the display related code.

[jhedberg]

Is this still reproducible with the latest main branch?

[laodzu]

Ok, so I was literally too blind to see the obvious here. As I enabled all the debug help that I could think of, I was under the impression that a stack overflow would be noted, but on this platform in this configuration this is not the case. Doubling the main stack from 4k to 8k solves the problem. In the working example I measured the stack usage:

uart:~$ kernel thread stacks
0x800807c0 lvgl_flush_thread                (real size 1024):   unused  816     usage  208 / 1024 (20 %)
0x80080688 input                            (real size 1024):   unused  840     usage  184 / 1024 (17 %)
0x800802d8 shell_uart                       (real size 2048):   unused  984     usage 1064 / 2048 (51 %)
0x8008ca98 sysworkq                         (real size 1024):   unused  848     usage  176 / 1024 (17 %)
0x8007fdc0 logging                          (real size  768):   unused  560     usage  208 /  768 (27 %)
0x8008c898 idle                             (real size  320):   unused  256     usage   64 /  320 (20 %)
0x8008c970 main                             (real size 8192):   unused 3384     usage 4808 / 8192 (58 %)
0x8008e940 IRQ 00                           (real size 2048):   unused 1840     usage  208 / 2048 (10 %)
uart:~$ 

Obviously, 4k is not enough, but doubling it to 8k is wasteful.
I really wonder why this did not hit me on other platforms. I will do some more tests on other platforms to see if this solves the problem and then open a PR.