Issues with FPS and Screen Tearing on 7" LCD using STM32F767 MCU

[bCebesoyatMertech]

Hello everyone,

We are working on a project that involves an LCD display and we are using the STM32F767 MCU. We have designed the board to work with both a 4.3" LCD with a resolution of 480x272 and a 7" LCD with a resolution of 800x480. While we are satisfied with the performance on the 4.3" LCD, we are facing issues with the 7" LCD, particularly with the FPS (Frames Per Second) and screen tearing.

We were able to increase the FPS on the 7" LCD from 25 to around 65 by adjusting the LCDCLK value using the formula "TotalW x TotalH x refresh rate". However, we encountered visible tearing on the screen (moving and colorful lines) when using the RGB888 Color Format. Switching to RGB565 resolved these issues and provided a cleaner display. This effect was consistent across different UI designs.

We have tested different UI designs using both ST TouchGFX and Embedded Wizard, and observed the same results.

We suspect that the problem might be related to DMA2D or SDRAM, but we are not sure how to proceed or what tests to conduct to confirm this. Any insights or suggestions would be greatly appreciated.

System Summary:

• MCU: STM32F767ZIT6
• SDRAM: MT48LC4M32B2P-6AIT
• LCD: 800x480 24bit Parallel RGB

Thank you in advance for your help.

[Ayoub Cheggari]

Hello @bCebesoyatMertech ,

I think the issue relates to the performance of the mcu. The frame buffer here is quite big = 24bit*800*480/8 = 1.1Mb compared to 16bits*800*480/8=768kb. I am not sure if this mcu has the chrom art, but you need a HW accelerator.

Also, if you are using a double frame buffer, you can test with only one first, because that will double the amount of data to handle.

Thanks,

Ayoub

[bCebesoyatMertech]

Hello @Ayoub Cheggari ,

Thank you for your insights.

You are correct about the frame buffer size calculations. Our MCU, the STM32F767, does have Chrom-ART Accelerator, which I assume is what you're referring to as "Chrom-ART DMA2D."

I'm not entirely sure what you mean by "HW accelerator." Could you please elaborate on that?

We have also experimented with both double and single frame buffers and observed that the issue persists in both configurations.

Additionally, I'd like to mention that we are using a 32-bit SDRAM, but due to hardware constraints, we are currently operating it at 16-bit. We plan to upgrade to 32-bit operation both in hardware and software and will report back with the results. I'm curious to hear from the community whether this limitation could be related to the issues we're facing.

Looking forward to your further suggestions.

Best regards,
bCebesoyatMertech

[Ayoub Cheggari]

Hello @bCebesoyatMertech,

Yes, you are right! I meant by that the Chrom-Art Accelerator. I said it's HW accelerator because it's HW driven not SW.

I remember we had the same issue a while ago and we increased the performance but don't remember how!

I remember there was some bus starvation because LTDC and FMC are using the same AXI bus.

//
// Ensure that the LTDC has the highest level of QOS to avoid bus starvation and subsequent visual artifacting.
//

volatile SHIP_U32 rqos = GPV->AXI_INI6_READ_QOS;
rqos |= 0x0000000F;
GPV->AXI_INI6_READ_QOS = rqos;
volatile SHIP_U32 wqos = GPV->AXI_INI6_WRITE_QOS;
wqos |= 0x0000000F;
GPV->AXI_INI6_WRITE_QOS = wqos;
//
// DMA2D is just below that
//
//rqos = GPV->AXI_INI5_READ_QOS;
//rqos |= 0x0000000E;
//GPV->AXI_INI5_READ_QOS = rqos;
//wqos = GPV->AXI_INI5_WRITE_QOS;
//wqos |= 0x0000000E;
//GPV->AXI_INI5_WRITE_QOS = wqos;
//
// Enable unaligned accesses via disabling the trapping of them via exception.
//
SCB->CCR &= ~(uint32_t) SCB_CCR_UNALIGN_TRP_Msk;

GPV->AXI_TARG5_FN_MOD_ISS_BM = 1;

please to read this and check what needed for your application!

Ayoub