Weird horizontal artifacts in touchGFX buttons

[BWKidd]

Hi Folks and Happy New Year!

I've been trying to track down a problem I'm having with my project for several months now. Essentially I'm getting these red-ish lines through portions of my buttons, but only when (I presume) they are drawn or redrawn - namely when the screen first loads, when they are pressed, or when as in this example, they have text drawn over them that updates. 

In the case of the above picture, I've been able to get the lines to appear more consistently by layering some text over top of some of the buttons and then updating that text with each tick where it says "Tick Counter: xxxx". I managed to luck out and have it appear on the "Cancel" of the cancel button this time, though it probably only happens about 1 out of 10 times when the screen loads.

These lines have been appearing pretty consistently throughout my development on the project, and they seem (though I'm still not completely sure) to be happening regardless of my application code. The reason I say this is that I've commented out large portions of my application code and had them still appear. Frustratingly, they are not consistent. I can do a build, have them appear, and then insert a trivial line of code (even a NOP), and then they will disappear, only to reappear again after I add a few more lines.

This really seems to point to some sort of issue where I'm writing off the edge of an array or something (it seems that parts of my frame buffer are getting inadvertently overwritten? But then why just buttons? And why does it still happen when I essentially remove my application code?) 

I've included my TOUCHGFXHAL code that has my driver code in it.

Details on my project:

MCU: STM32L496VGTN

Display: NHD-2.8-240320AF-CSXP-FT (ST7789 Controller) connected via FMC 16-bit parallel

External Flash: MT25QL128A using quad-spi with a custom loader

Firmware details: No RTOS (Bare Metal/super-loop)

Touch GFX Configuration:

Other possible helpful details:

• My display has no TE line, so I'm updating it manually using a timer at 10Hz by calling Oswrappers::signalVSync(). I had this called in the timer callback function, but recently moved it into the main loop and the problem actually seemed to happen more consistently if anything.
• I've confirmed that these artifacts are actually contained in the framebuffer, so its not some sort of electrical noise that's corrupting pixels as they're transmitted to the display.

Any tips, tricks, or advice towards debugging this issue would be greatly appreciated. You might say figuring this out has become my new year's resolution!

 

[BWKidd]

I'm glad you were able to take a little break, and as it turns out I did pretty much the same thing!

I currently have this at the bottom of my linker file:

  ExtFlashSection :
  {
  	*(ExtFlashSection ExtFlashSection.*)
  	*(.gnu.linkonce.r.*)
  	. = ALIGN(0x4);
  } >QUADSPI
  FontFlashSection :
  {
  	*(FontFlashSection FontFlashSection.*)
  	*(.gnu.linkonce.r.*)
  	. = ALIGN(0x4);
  } >QUADSPI
  TextFlashSection :
  {
  	*(TextFlashSection TextFlashSection.*)
  	*(.gnu.linkonce.r.*)
  	. = ALIGN(0x4);
  } >QUADSPI

 I commented out the "FontFlashSection" so that it (presumably) remapped it to internal flash, and the character corruption for 2, 3, 5, 6, 7, and 9 went away! So, does that indicate that we are back to some sort of issue with reading my quadspi flash at times then? Strange how it is so consistently affects only certain numbers. I'll dig into the quadspi flash in greater detail hopefully later this week or early next week - right now the focus is on re-doing the PCB layout out my prototype board for some mechanical and minor electrical changes.

[mathiasmarkussen]

It does seem like it might be related to the external flash. The fact that it only affects certain characters probably indicates that it has something to do with where the characters are placed, or that the data is simply not written correctly to the flash in the first place. That would make the comparison of the flash to the actual compiled contents of the font files interesting. The font files are in TouchGFX/generated/fonts/src. You should be able to locate them in the .map file, and compare the memory contents with the contents of your elf/hex file or directly with the contents of the .cpp file.

I can see that placement of the two sections has been commented out in the TouchGFX board setup project for L496 a long time ago, so it might also be a general problem for L4 somehow, although I have no idea what that would be.

If you are able to keep your fonts in internal flash, I guess you are fine, although I might be inclined to distrust your external flash a little in general, considering that making it go faster made the other problem disappear as well, but that might also have been some kind of race condition.

[BWKidd]

Somehow I missed something. I've now got the quadspi flash prescaler set to 0 (Full 80 MHz) and the character distortion goes away. I thought I had tried it in this configuration already (and I know you told me to do it too!), but something is different this time.

I finally broke down and borrowed some test code from my external loader development to really try to test out the external flash. Basically I erase the whole flash, load it up with 0 to 255 repeatedly throughout the memory, set it into address mapped mode and then read through the entire memory. When I did this, I didn't have any problems when reading it in software (looping through memory with a for loop and checking each byte against the expected value)...

But, if I did the same thing with DMA - I started getting mis-reads, where the read would return a byte or two ahead in memory!

This problem went away if I changed the quadspi prescaler from 2 to 0. It also works if I change SampleShifting to QSPI_SAMPLE_SHIFTING_HALFCYCLE, so I must have some sort of signal timing issue. Kinda wish I had a logic analyzer right about now.

I'm going to apply these changes to my production firmware and see what happens.

[BWKidd]

Initial results look very positive. I don't have any red-line artifacts (I think those went away with enabling chrom-art in the touch GFX settings), and I don't have the weird character distortions (those appear to be fixed by setting the pre-scaler to 0, or more likely, setting the sampling to half-clock). My code for transferring data from the frame buffer to the display is now using DMA (in two equal chunks since the frame buffer is larger than the size limit for the DMA), which drastically reduces the CPU usage.

So tentatively, things are looking much better. I will post a more definitive results hopefully in a few days with a more detailed summary once I have more confidence that this is fixed. I'm so very grateful for your help @mathiasmarkussen .