Showing results for 
Search instead for 
Did you mean: 

Fail to display expected colour after successful lcd initialization

Associate II

I'm currently working on a project that involves using an STM32U5 microcontroller to drive a TFT LCD display through the MIPI DSI interface. After managing to initialize the LCD display (which shows the default layer in blue, indicating success), I've encountered a perplexing issue that I hope to find some assistance with here.

Despite the successful initialization, I'm only able to get a white image on the display, regardless of attempts to change the screen's color. Below is the approach I've taken, including the function intended to fill the layer0 with a specified color :

The function is designed to iterate through the frameBuffer, setting each pixel to a color defined by the RGB888 macro. After filling the buffer, I use HAL functions to update the LTDC frame buffer address and refresh the display. However, the screen remains white, even after executing this function with various color parameters.

Here are some specifics about my setup and what I have checked so far:

  • The frameBuffer size and alignment are correctly configured for the display's resolution and color depth.
  • I've double-checked the LTDC configuration, ensuring the pixel format, window size, and frame buffer address match the display's requirements.
  • The display's datasheet was reviewed to confirm the correct timing parameters and color format (I've used RGB888).

I'm reaching out to see if anyone has faced a similar issue or could offer any insights into what might be going wrong. Any advice on additional debugging steps or configuration checks would be greatly appreciated. Could there be an issue with the way I'm using the HAL_LTDC_SetAddress and HAL_LTDC_Reload functions, or perhaps something else I'm overlooking?

Thank you in advance for your help and suggestions!


uint32_t frameBuffer[DISPLAY_WIDTH * DISPLAY_HEIGHT]; // Correct size for 32-bit access per pixel


#define RGB888(r,g,b) (((r) << 16) | ((g) << 😎 | (b))


void FillScreenWithColor(uint8_t red, uint8_t green, uint8_t blue, uint32_t n_pixels) {

uint32_t color = RGB888(red, green, blue);

uint32_t* tempBuffer = frameBuffer; // Use a temporary pointer for iteration


while(n_pixels > 0) {

*tempBuffer = color; // Set the current pixel to the specified color

tempBuffer++; // Move to the next pixel

n_pixels--; // Decrement the pixel count



// Use the original framebuffer address to update LTDC, as tempBuffer has been incremented

HAL_LTDC_SetAddress(&hltdc, (uint32_t)frameBuffer, 0); // Assuming layer 0

HAL_LTDC_Reload(&hltdc, LTDC_RELOAD_IMMEDIATE); // Refresh the display



void InitializeDisplay(void) {

// Previous initialization code here...


// Enable the LCD, send Display ON command



// Start PWM Timer channel for backlight

(void)HAL_TIM_PWM_Start(&htim8, TIM_CHANNEL_2);


// Set maximum brightness (assuming 0-200 range for demonstration)



// Fill the screen with red color





No details on the panel, panel initialization or those for the LTDC or DSI on the STM32 side..

Hard to judge if any of that is correct from here.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..

thanks for your reply ,If i can display the default layer colour on the display , is it not sufficient to say that the display was initialized correctly ? 

I have attached the ltdc file , please note i've purposly moved the position of the layer0 here .






Not really an expert in LTDC buffers, but surely RGB888 is a 24 bits per pixel format. You're using 32 bits per pixel. Do they really expect you to only have 75% storage efficiency?

Note that R, G, B lit up randomly will appear white. Use a magnifying glass or phone camera or good eyesight and you can probably see a few pixels to see what's really going on.


If you feel a post has answered your question, please click "Accept as Solution".

I can't tell from the buffer display , i can see clear horizontal lines with some blue in between ? it's not very clear what's happening , i have also tried using rgb565 format with a 16 bit buffer (2 bytes per pixel) but still same result , i have attached a picture of the case , please note that i have purposely modified the positioning of the frame .


If its really 24bit pixel, this might work:

uint8_t frameBuffer[DISPLAY_WIDTH * DISPLAY_HEIGHT*3]; // Correct size for 24-bit access per pixel

void FillScreenWithColor(uint8_t red, uint8_t green, uint8_t blue, uint32_t n_pixels) 

	uint8_t* tempBuffer = frameBuffer; // Use a temporary pointer for iteration

	while(n_pixels > 0) 
		*tempBuffer = red; 
		*tempBuffer = green; 

		*tempBuffer = blue; 

		n_pixels--; // Decrement the pixel count


Looks very much like the pixels in your buffer are not aligned with what the screen is expecting. This would suggest the 24/32 bit inconsistency is a problem.

If you feel a post has answered your question, please click "Accept as Solution".

Hi maybe go back to start. Learn how LTDC controller works. You comment reload func as screen refresh, you miss completely here. This command reload register setup in controller not display.

Normal in single buffer mode is init address and all other before you start DSI. Not change this address in code.

My tip your alpha setup for pixels is bad and layer is invisible = irelevant how color in framebuffer.

How you generate code MX or other way?