Issue with Changing Pixel Format on STM32F769i

[Michael K]

I followed this guide to changing the pixel format of an application. Although my TouchGFX designer file does not have the code listed above the framebuffer pixel format table 2/3 of the way down the page, in the Designer itself it reports 16bit color and RGB565. However, when I build and run my application, the screen appears corrupted and then freezes. The stack trace is attached, but it appears that during the constructor call of one of my custom containers, a PainterRGB888 reference is called and an assertion fails(?), hanging the program.

If I make a simple screen that doesn't have that custom container, the display still corrupts though it doesn't seem to crash.

The application template for the STM32F769i only lists 24bit color depth as an option. Is this a hardware constraint?

[Martin KJELDSEN]

It's not a hardware constraint - In fact, most of the Application templates should have been updated to default to 16bpp instead of 24. The reason why the templates only support a single color depth now is that we're using CubeMX/Generator to create them.

There must be a correlation between the hardware configuration and the TouchGFX configuration, or you'll either get asserts or see weird things. Did you check the support site for a guide on changing color depth? If you can't find it i'll help.

/Martin

[AME MCU Support Center BB]

Hi Michael,

One function I think it still needs to be modified: HAL_DSI_EndOfRefreshCallback() to support 16BPP.

I will be helping you regarding as I'm interested in this support case.

With regards,

Badreddine

[AME MCU Support Center BB]

What I can think of - in HAL_DSI_EndOfRefreshCallback() change:

LTDC_LAYER(&hltdc, 0)->CFBAR = ((uint32_t)currFbBase) + 448 * 3;

LTDC_LAYER(&hltdc, 0)->CFBLR = ((832 * 3) << 16) | ((REAL_WIDTH) * 3 + 3);

LTDC_LAYER(&hltdc, 0)->CFBLR = (((832 * 3) << 16) | ((WIDTH * 3) + 3));

by

LTDC_LAYER(&hltdc, 0)->CFBAR = ((uint32_t)currFbBase) + 448 * 2;

LTDC_LAYER(&hltdc, 0)->CFBLR = ((832 * 2) << 16) | ((REAL_WIDTH) * 2 + 3);

LTDC_LAYER(&hltdc, 0)->CFBLR = (((832 * 2) << 16) | ((WIDTH * 2) + 3));

3 for 3 bytes (24BPP) needs to be changed to 2 for 2 bytes (16BPP)

[AME MCU Support Center BB]

Here is the procedure:

1. Change the LTDC configuration in CubeMx to RGB565 - make sure DSI uses RGB565
2. In additional software change RGB888 to RGB565
3. Change HAL_DSI_EndOfRefreshCallback() as described above
4. replace

OTM8009A_Init(OTM8009A_FORMAT_RBG888, LCD_ORIENTATION_LANDSCAPE);

by

OTM8009A_Init(OTM8009A_FORMAT_RBG565, LCD_ORIENTATION_LANDSCAPE);

[Michael K]

Apologies for the late reply - this issue fell off my radar while I was working on other parts of my application. The procedure you described works but causes graphical glitches when TouchGFX is configured to use ChromArt. Especially in areas of transparency, elements below appear to "bleed through" the higher level elements. Disabling ChromArt seems to solve the problem, albeit at some performance cost in certain situations.

Any ideas related to ChromArt? I've tried with the original application template settings, as well as the settings listed in the board bring up documentation (https://support.touchgfx.com/docs/development/board-bring-up/how-to/08-hardware-acceleration) and both result in the same issue.

[Michael K]

In addition, I was using a Painter888RGB in one of my customer containers, which was the actual root cause of the particular assertion failure shown in the stack trace in the OP. Replacing it with a Painter565RGB resolved that particular issue.