If you are seeing pixel errors on the display it is most 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 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. 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 commenting out the specific 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. The external flash contents may or may be correct when reading from debugger.
The visual manifestation will be similar to 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 either 2 or 3. 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 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 runs. This will also remove the problem but will severely impact rendering performance. To enable this configuration, insert the following in touchgfx_init():
Faulty external flash loader
If you are using a flash loader distributed by TouchGFX, we might be able to provide the source code for the loader. Note that some of our flash loaders are actually obtained by MCU or board vendors, and these we do not have the source code for. Otherwise contact your hardware supplier for assistance.
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.