Unexpected white lines immediately proceeding and following assets

[DWeie]

I have a proof of concept to use touchGFX to implement display on some custom hardware. The processor is an STM32F746BGT6 part. I've been able to execute touchGFX4.10.0 from the STM32CubeIDE MX view and use it to generate code. The issue can be observed in the attached video. On the first screen, bracketing the first button, there are two vertical white lines. This same type of line can be seen on the second screen interspersed in the first half of the text. I've moved the assets into local flash to ensure that there isn't some strange issue with QUADSPI.

I'm unsure what the cause of this could be. I can confirm that the contents of the frame buffer, when viewed in debug mode, do in fact contain these white lines. This indicates to me that there might be some issue in drawing the screen. Any help would be appreciated.

Don

[DWeie]

Hey Martin,

Thanks for following up. I hope you had a relaxing vacation!

I have unfortunately not made progress on this. It is the last remaining obstacle for this phase of the design. I shared a video a little further up the conversation of the results I observed when initializing with the NoDMA configuration option.

I've verified that the issue is not with the QUADSPI. And I was able to manually write to the frame buffer the value for "green" and both verify that each address contained the written value with a check loop, and that the entire screen was in fact green. This tells me that the DRAM framebuffer is working properly. With the hardware verified in such a manner I am unsure where to look next to resolve this.

Don

[DWeie]

Hey Martin,

Thanks for following up. I hope you had a relaxing vacation!

I have unfortunately not made progress on this. It is the last remaining obstacle for this phase of the design. I shared a video a little further up the conversation of the results I observed when initializing with the NoDMA configuration option.

I've verified that the issue is not with the QUADSPI. And I was able to manually write to the frame buffer the value for "green" and both verify that each address contained the written value with a check loop, and that the entire screen was in fact green. This tells me that the DRAM framebuffer is working properly. With the hardware verified in such a manner I am unsure where to look next to resolve this.

Do you have a recommendation for what I should try next?

Thanks,

Don

[Martin KJELDSEN]

Hi @DWeie​,

That's unfortunate! I checked your video. You say you can write to RAM and read back expected values. Have you tried verifying a frame that you can actually see is wrong? E.g. one of the frames in your video. Here's a few other things you can try.

• Single buffer mode
• hal.LockDMAToFrontPorch(true) to rule out memory contention issues where DMA2D and LTDC are accessing ram at the same time.
• Slower pixel clock

/Martin

[DWeie]

Hey Martin,

I have checked the frames in the past using the memory browser available in the STM32CubeIDE. When I viewed the contents of the frame buffer I did see the values for white (0xFFFFFFFF). I have experimented with slowing down the pixel clock. It resolved some other issues but did not remove the line glitches.

After reading your post I tried single buffer mode, enabling the LockDMAToFrontPorch, and both at the same time. No change in the artifact was observed.

I've observed something new that might help get to the bottom of this though. The videos and images I've shared so far have all occurred using RGB565. I've changed the display to use RGB888 and discovered that the error changes (see attached). It may be difficult to see but now i the place where 1 white line existed, two parallel lines are observed and are not all white.

[DWeie]

Hey Martin,

I'm wondering what other thoughts you might have on this?

It really seems like an SDRAM timing issue, but since I'm able to write, then read and verify the entire range of memory the framebuffer exists in I'm not sure what could be happening. As mentioned, I am able to verify that the display bugs DO exist in the frame buffer memory.

I've been trying to look into the DMA2D settings but haven't found anything that seems like an obvious culprit. I'm wondering if there's an issue with the drawRectangle code? Specifically to do with the X-axis.

Since I'm able to recreate this exact bug at various locations on the screen it doesn't seem like the error has to do with any specific row or column access of the SDRAM.

[DWeie]

To anyone who ends up having the same problem, I was finally able to resolve it. The issue was caused by improperly initialized DQM lines to my DRAM chip.

[Martin KJELDSEN]

Nice find, @DWeie​!

That wasn't an easy one.

/Martin