If you are seeing pixel errors on the display it is commonly due to one of three causes. This article explains how to determine the exact problem and what course to take to resolve it.
The three most likely sources of pixel error issues are:
- LCD pixel clock is too high, causing LCD controller FIFO underrun
- Faulty external flash loader
- Incorrect flash/SDRAM memory configuration causing unstable read/writes
1. Pixel clock too high
This is usually only a problem if pixel clock is around 30MHz or higher. The problem occurs because TouchGFX is rendering to one frame buffer in SDRAM while the LCD controller is reading from the other frame buffer. Depending on bus arbitration for the concrete MCU, this may cause the LCD controller to be denied SDRAM access for a time, long enough for the LCD FIFO to become starved. If this happens the pixel values on the RGB lines will be incorrect.
This will most often manifest as partial lines being delayed (shifted), and occuring in conjuction to frame buffer changes only. So the display might look completely correct but as soon as you press a button (causing some drawing), you will see glitches until the drawing is completed, after which the display may look correct again.
In order to determine if this is the problem, try reducing the pixel clock frequency, to the lowest value allowed by the display. This will probably severely reduce frame rate and might not look good, but at least the pixel errors should disappear.
You can also configure the LCD controller to generate an interrupt in the event that a FIFO underrun occurs, and verify via debugging if this interrupt is fired.
A third option is to use a debugger to dump the contents of the frame buffer. If the pixel values in the frame buffer are correct, then the cause is almost definitely in the LCD controller (or possibly in the wiring of the RGB/control signals on the PCB). Try replacing the displayed image assets with something that is easy to verify like completely solid white, red, black images.
2. Faulty external flash loader
It is obvious that if the contents of the external flash are not correct, then you will see pixel errors. Flash programmers do not always verify that the contents programmed are correct.
If you have a faulty external flash loader, the contents of the frame buffer will be incorrect in almost all cases. The errors on the display will be present also when no frame buffer changes are taking place, and typically the errors will be exactly the same every time a specific image is being displayed.
If possible, try moving your images to the internal flash (by changing the ExtFlashSection directive in your linker script). You will probably only be able to fit a very limited amount of images in the internal flash.
Alternatively, again try replacing your real images with solid color dummies and use a debugger to examine the contents of the external flash at runtime. The map file will tell you the address of each image in the external flash.
3. Incorrect flash/SDRAM memory configuration
This most often relates to the timing parameters being set to be too fast when configuring the external memory controller. It may be either the external flash (causing incorrect reads of pixels) or the SDRAM configuration (causing incorrect reads or writes).
If this is the cause, the frame buffer contents will most often be incorrect, but especially when the cpu is busy. The external flash contents may or may not be correct when reading from debugger.
The visual manifestation will be similar to section 2. but might be more dynamic in nature (not necessarily exactly the same pixel errors every time a certain screen is being drawn).
Try modifying the timing values of the external memory controller to more relaxed values.
Debugging the issue
Are the pixel errors only occurring during times when the frame buffer is being drawn (screen contents are changing), so that once the drawing completes, the display looks stable without errors? This would point to pixel clock being the problem. If the pixel errors are more or less constant, it is most likely due to the flash loader or pixel clock. Follow the description in the relevant sections above to determine which is the problem.
Resolving the issue
Pixel clock too high
Reduce the pixel clock to the highest possible value that does not cause pixel errors. Note that this will reduce your VSYNC frequency, which should be kept at around 60Hz. To increase the VSYNC frequency to still match ~60Hz, decrease the values of horizontal and vertical front porch. You probably do not need to match 60Hz exactly, most displays can handle around 50Hz VSYNC, but it should not be slower than that.
If this is not possible due to limitations of the concrete display, you will need to consult your MCU FAE contacts for advise on how to proceed.
As a last resort, TouchGFX provides a configuration setting that prevents TouchGFX from rendering while the LCD controller transfers pixels. This will also remove the problem but will severely impact rendering performance. To enable this configuration, insert the following in touchgfx_init():
Incorrect flash/SDRAM memory configuration
Try slowing down the timing of the memories in the configuration of the external memory controller. If this does not help, please contact your hardware FAE for assistance as it is outside the scope of TouchGFX.