LVGL fails to draw properly when LV_DRAW_COMPLEX=1(stuck in vglite)

[Vinos]

Chip:MIMXRT1176DVMAA
LVGL:8.3.2
OS:FreeRTOS

Hello, due to project requirements, I initially had a test board with MIPI LCD and SDRAM. My program runs on the SDRAM, and all variables are defined in the SDRAM as well. In this case, all the functions of the program work fine. Then, I obtained an final board which had a different MIPI screen. Due to size requirements, it uses HyperRAM instead. The program now runs on NOR Flash, and I defined all the large variables required by LVGL in the HyperRAM. The rest of the program, including lv_conf.h, remains unchanged.

However, in this situation, I encountered some strange issues. On my existing GUI, there are multiple screens. Screen 1 has some labels, and Screen 2 has a list. If I directly open Screen 2, the program always freezes in the lv_task_handler. If I first open Screen 1 and then open Screen 2, Screen 2 can load correctly. However, if I repeatedly load Screen 2 multiple times, the program still freezes. Additionally, I noticed that the display of components like switches and buttons is not normal.

Therefore, I created a separate LVGL project and a simple screen. It contains a button, and I have enabled LV_USE_PERF_MONITOR. The background of the button should be blue, but each time after power-on, it shows one of the following four behaviors.

I found that the code always gets stuck at lv_event_send(obj, LV_EVENT_DRAW_MAIN, draw_ctx), and ultimately, it gets stuck at lv_draw_sw_rect. The call process of lv_draw_sw_rect is as follows:

The program stuck in vg_lite_finish() in the function lv_event_send(obj, LV_EVENT_DRAW_MAIN, draw_ctx) rather than every time vg_lite_finish() is called in other place.

Then, I tested by disabling LV_DRAW_COMPLEX or LV_USE_GPU_NXP_VG_LITE and performed multiple power-on tests. The display was normal in all cases. However, I need to enable LV_DRAW_COMPLEX to draw these shadows. What could be the possible reasons for this situation?

[jingpan]

Hi @Vinos ,

LV_DRAW_COMPLEX is enabled by default. I can't repeat this problem on my board. Can you share the simplified demo or explain how you make the demo?

Regards,

Jing 

[Vinos]

This problem is difficult to repeat, because in my previous board, I had no problem using SDRAM to store these variables and code. I have located the VGLite problem in LVGL, the program is stuck in vg_lite_finish, and it is probabilistic. Turning LV_DRAW_COMPLEX off is only in some cases the GUI will not stick, but it does not completely solve the problem, only turning VGLite off can completely solve the problem.

This must have something to do with Cache, but I checked the MPU configuration and there was nothing wrong with it, and the VGLite code would take a long time to understand.

The difference between the two boards is that the former's code and variables are stored in SDRAM(200MHz), while the current board code is run in NOR Flash(200MHz), and the variables are stored in HyperRAM(400MHz).

[jingpan]

Hi @Vinos ,

If VGLite is used, it will access HyperRAM by DMA. That may cause cache problem. You can try to put data in noncacheable area of hyperRAM.

Regards,

Jing

[Vinos]

I understand. I have built a test program, and I directly declared a portion of the HyperRAM memory in the MCU Setting of MCUXPresso IDE. I haven't made any changes to the variables declared with AT_NONCACHEABLE_SECTION_ALIGN in the program. I have checked the MPU configuration function during debugging, and this memory segment is indeed configured as non-cacheable.

Additionally, if DMA is used without declaring it as non-cacheable, it may result in data inconsistency , which could manifest as abnormal screen displays,the LVGL shouldn't have freezed. Currently, although the screen shows anomalies for some components like switches and buttons, the program occasionally freezes and there is a small chance that these components are displayed correctly.

The program gets stuck at vg_lite_finish(), and upon further debugging, I found that it is waiting for a semaphore in vg_lite_os_wait because GPU interrupt is not being generated.

I would like to know if there are any specific hardware considerations for the GPU in the RT1170, or if this issue is primarily software-related?

[jingpan]

Hi, @Vinos ,

Is that means when you download and debug, the system works fine. But when power off and on again, it can't work? How about screen 1/screen 2 switch problem, still there?

If you don't use GPU, is the problem still there?

Regards,

Jing

[Vinos]

Some modifications have also been made to the hardware power supply. I want to know which pin power supply is used by the GPU, and how to check whether the GPU-related modules have power supply

[jingpan]

Hi @Vinos ,

No I haven't RT1050 hyperRAM EVK. And it seems the problem is related to GPU ad LVGL. This board can't help. 

GPU has same power source as M7 core. Not a standalone source.

GUI Guider V1.6 will be unveiled on 7/31. It has much improvement and LVGL version become v8.3.5. Can you wait several days for it?

Regards,

Jing

[Vinos]

I have tried to port the latest version 8.3.8 of LVGL from GitHub, and indeed, there were significant changes in the vglite part of the code. However, it didn't solve the problem.

Can I send my board to you guys and help me debug it through this link?
https://support.nxp.com/s/?language=en_US

[jingpan]

Hi @Vinos ,

I see that RT595 LVGL project create by GUI Guider use Flexspi1 PSRAM to buffer data. It works fine. Can you compare them?

Normally we do not debug on customer's board. But yes you can create a ticket in support ticket system. Some information we can only share there.

Regards,

Jing

[Vinos]

Thank you for your help.Where can I get the RT595 code please?Does the code generated by GUI Guider link related variables to RAM?

[jingpan · Accepted solution]

Hi @Vinos ,

Use GUI Guider to create a RT595 project. It use psram by default. It doesn't link a buffer to psram, it just use a pointer.

Regards,

Jing

[Vinos]

Thank you very mush,the issue is solved!
It's the issue of FlexSPI configuration.

[Vinos]

The performance of each debug is the same as that of each power-on,they all don't work.Sometimes the screen can be displayed normally, but the probability is very small.

The problem of screen switching exists, such as opening the screen 1 directly after powering on, the high probability is that it will be stuck, but opening the screen 2 and then opening the screen 1 can be normal, and this is also probabilistic, there is a probability of about 1/4, opening the screen 1 directly after powering on can also be displayed normally.

After vglite is disabled, all the components and screens are displayed normally.But I have an interface where the MIPI LCD shows images from the MIPI camera, without vglite turned on, and there are short green or white lines on the left and right sides of the screen.Camera images display normally(without short lines both sides) if vglite is turned on.

[jingpan]

Hi @Vinos ,

Can you please slow down the hyperRAM? I tend to believe this is caused by timing issue.

Regards,

Jing

[Vinos]

I've tested slowing down HyperRAM from 200MHz to 50MHz,the cpu occupation rises to 99%.Is it normal?I have enable -O3 compiler option.
Also I've tested 100MHz,the problem still exists.

There is a variable "s_frameBuffer" defined in lvgl_support.c,it's 700KB at my screen resolution.So I have to define it in a non-cacheable region of the HyperRAM.

I have noticed that FlexRAM can be configured to merge ITCM,DTCM and OCRAM into one memory.I want to place the "s_frameBuffer" to internal RAM to troubleshoot if it's caused by HyperRAM.How can I configure the FlexRAM?

[jingpan]

Hi @Vinos ,

You can refer to AN12077 for how to config flexram.

Regards,

Jing

[Vinos]

I haven't tried FlexRAM yet because besides LVGL's buffer, vglite's buffer also requires more than 1MB of space.But I have reconfirmed that the allocation of LVGL variables (cacheable or non-cacheable) and the MPU configuration are correct. I suspect there might be some conflicts between the GPU and FlexSPI interface.

It is highly likely that there is a missing cache flush call in one of the VGLite functions. However, the vglite code related to this issue is quite complex, and there is limited documentation available.Studying combination between GPU and LVGL in depth requires a lot of knowledge and time.

According to AN12239, the MIMXRT1050 EVKB board has a HyperRAM interface. Do you have the board with HyperRAM there? I can port an LVGL project based on HyperRAM for the RT1050 platform and provide it to you for testing, to help me eliminate this possibility.