Peripheral Function Abnormalities Caused by Adding LTDC/LVGL to the STM32H7 Project

[QingWu]

Hello,
I am developing an embedded project using the STM32H7 microcontroller, integrating FreeRTOS, FatFs file system, USB mass storage device (USB flash drive) functionality, SD card reading/writing,
UART communication, and ADC sampling. My system uses LVGL as the graphical user interface (GUI) library and drives the LCD through LTDC.

Core issue phenomenon:
I observed that the system's functional behavior has a direct and consistent correlation with the on/off state of the LVGL screen:
DISPLAY_ENABLE is a macro definition I created to control whether to use the screen.

When the screen is off (DISPLAY_ENABLE = 0):
All functional modules (USB mass storage mounting and writing, UART communication, ADC sampling, SD card reading/writing, database operations) work normally.

When the screen is on (DISPLAY_ENABLE = 1), two different phenomena occur:

Phenomenon 1: When test buffers (writeBuffer/readBuffer, 512 bytes each) are located in the data segment:

USB mass storage device fails to mount (output log shows "Mount failed with error: 1")
UART communication functions work normally
ADC sampling functions work normally
SD card reading/writing and database operations work normally

Phenomenon 2: When test buffers (writeBuffer/readBuffer) are declared inside functions (i.e., in stack space):

USB mass storage device mounts and writes normally
UART communication functions fail to work properly
ADC sampling functions fail to work properly
SD card reading/writing and database operations work normally

Code snippets related to my LVGL/LTDC:

#define LCD_WIDTH    320
#define LCD_HEIGHT   240

static uint16_t fb[LCD_WIDTH * LCD_HEIGHT] = {0};

// Only modified this line after CubeMX generation:
pLayerCfg.FBStartAdress = LCD_GetFrameBufferAddress();

// When DISPLAY_ENABLE = 0; LCD_GetFrameBufferAddress() returns 0
// When DISPLAY_ENABLE = 1; LCD_GetFrameBufferAddress() returns (uint32_t)fb


void InitTft(void)
{
    lv_init();                            
    lv_port_disp_init();   
	
		
	
    tftTaskHandle = osThreadNew(TftTask, NULL, &tftTask_attributes); 
    LVGLTaskHandle = osThreadNew(LVGLTask, NULL, &LVGLTask_attributes);

    lvglMutexHandle = osMutexNew(&lvglMutex_attributes);
	
}

/**
 * LVGL requires a buffer where it internally draws the widgets.
 * Later this buffer will be passed to your display driver's `flush_cb` to copy its content to your display.
 * The buffer has to be greater than 1 display row
 *
 * There are 3 buffering configurations:
 * 1. Create ONE buffer:
 *      LVGL will draw the display's content here and writes it to your display
 */

/* Example for 1) */
static lv_disp_draw_buf_t draw_buf_dsc_1;
static lv_color_t buf_1[MY_DISP_HOR_RES * 10];                          /*A buffer for 10 rows*/
lv_disp_draw_buf_init(&draw_buf_dsc_1, buf_1, NULL, MY_DISP_HOR_RES * 10);   /*Initialize the display buffer*/

InitTft is the main screen thread.

I suspect that when LVGL is active, USB, UART, and ADC fail. I strongly suspect that the large static frame buffer (fb) is causing RAM address conflicts and impacting the consistency of critical peripheral DMA buffers and L1 Cache.
The above is the phenomenon I discovered and my doubts during testing. I want to know if this is the cause, or tell me what is causing it. I hope you can help me solve it. Thank you very much.
Thanks.

[Saket_Om]

Hello @QingWu 

Did you try to increase the stack size? 

[QingWu]

Hello,@Saket_Om
Attempts to Adjust Stack and Heap Sizes
Regarding the attempts to adjust stack and heap sizes: I have tried increasing the stack size, but the problem still persists.
Current Configuration
In Project Manager → Linker Settings of CubeMX, both Minimum Heap Size and Minimum Stack Size have been set to 0x2400.
Attempted Adjustments
Increased both stack and heap sizes to 0x5000 or even larger.
Increased only the heap size.
Increased only the stack size.
Phenomena After Adjustment
When both stack and heap are increased simultaneously: SD card mounting fails, and the serial port does not work.
When only the heap or stack is increased: The SD card can be mounted, but the serial port still fails to work properly.
When only the heap or stack is adjusted to 0x8000: SD card mounting fails.

In addition, the stack size configuration of FreeRTOS is as follows: TOTAL_HEAP_SIZE is 81920 bytes.
Conclusion
Simply increasing the stack and heap sizes cannot resolve the compatibility issue between LTDC+LVGL and peripherals such as ADC/serial port.
Thanks.

[Saket_Om]

Hello @QingWu 

Please ensure that large buffers (framebuffer, heap, stack) are not overlapping.

[QingWu]

Hello @Saket_Om
Through examining the .map file, it was found that when the screen is turned on, the system's total memory usage increases from 346KB to 481KB, with the display module occupying a 153KB buffer. At this point, the system exhibits abnormal phenomena: UART communication is interrupted, resulting in data transmission and reception failures; ADC sampling stops, causing the sampled values to remain fixed; and the USB connection is disconnected, making the device unrecognizable. Although the screen displays normally, other system functions fail to work properly.

In contrast, when the screen is not turned on, the system uses 346KB of memory without the LVGL module. Under this condition, UART data transmission and reception operate normally, ADC performs real-time sampling as expected, and the USB device maintains a normal connection for communication, ensuring stable overall system operation.

The essence of the problem is that when both the screen and the database are enabled simultaneously, other peripherals cannot function normally. Potential causes include memory access conflicts between LVGL's large 153KB buffer and communication modules, which lead to communication interruptions. It may also be due to insufficient memory or memory overlap issues. Please help analyze and resolve this problem. If the issue is insufficient memory, are there any chips with the same pin configuration as the STM32H743VIT6 but increased memory capacity—similar to a "Pro version"?
Thanks.