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

[Martin KJELDSEN]

Hi @DWeie​,

That does look strange. Can you try using the NoDMA class (rather than STM32F7DMA)? Then everything will be rendered by the MCU.

/Martin

[DWeie]

Martin,

Thanks for the suggestion. I gave it a try and the results were the same as before. If there is anything else you'd like me to try to get to the bottom of this please let me know.

Best,

Don

[DWeie]

I generated a screen with several text fields to see if a pattern emerged and I've attached the capture to this post.

If you look closely, it doesn't appear uniformly on the same letters, but it does appear uniformly in columns. As an illustration of this, compare the lower case t in the upper left with the lower case t on the upper right and see that they do not both have the white line glitch. Then compare that same 't' in the upper left with all of the 't' characters aligned in a column beneath it and see that they all have the same glitch of the same width and height. This seems like a clue but I haven't yet determined its meaning.

[Martin KJELDSEN]

Okay, thanks for the input. Have you tried a different font?

[DWeie]

Hey Martin,

I tried out some different font sizes. The white lines were still an issue, they just occurred on a different assortment of letters. Additionally, since the lines are bracketing a button on the home screen as well, I think the issue may be independent of the font selection. It's strange to me that the lines do not consistently appear around the same types of assets. As an example of this, when I place two of the same blue buttons on a screen, one may have lines while another may not.

Best,

Don

[DWeie]

Martin,

I took one of the buttons that had the white line glitch, and moved it slightly on the screen (X position 28 to X position 26) and the lines around it disappeared. I'm still unsure why this could be. I took some of the assets (blue round button unpressed) and removed the PRAGMA that placed it inQUADSPI. I verified in the .map file produced that that specific asset was located in on chip flash. This did not remove the line glitch so I can confidently say the issue does not stem from the external flash.

Additionally, if there were a SDRAM access issue causing the glitch it seems like it would be a very big coincidence for the glitch to behave so predictably in its positioning. I would also expect the graphical glitch to remain at fixed point on the screen so when the glitch around one button disappears after moving it makes me confident that the issue is not with the SDRAM access.

  

Where else should I be looking to resolve this? This is the last roadblock on the critical path so I'm anxious to make some progress.

Best,

Don

[DWeie]

I re-ran the configuration using the NoDMA class and received the results in the attached video. This makes it seem like there is still a rendering issue but I'm not sure what to make of it yet. I don't know why I didn't see this the first time I attempted the suggestion.

It might be difficult to see, but the location of the white spaces is no longer appearing as lines around assets, but somewhat random dots throughout the screen. When doing a screen transfer as a result of a button press, the white dots are dynamic and changing position on the screen. Once the screen settles and is no longer animating any change, the white dots are in a fixed position, but not necessarily the same position they were in the last time that the current screen was the active one.

Interestingly, there are issues with the text being displayed as well, but instead of white glitches, what I see is horizontal lines that match the background color cutting through the text.

[DWeie]

@Anders Nedergaard PETERSEN, I saw Martin's post about taking a well earned vacation and was wondering if you have any thoughts on this problem?

Thank you,

Don

[Martin KJELDSEN]

Hi @DWeie​,

I'm back. Did you progress on this?

/Martin

[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

[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]

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.