6748 LCDC Sync Lost

Thanks for the suggestions.  It appears as though I had a frame buffer alignment problem that may have caused my error.  However, now that I have found this and corrected it I am no longer able to load the palette.  I setup the frame buffer for palette only or palette and data and will never get PL = 1 in the LCD_STAT register when I enable the raster controller.

This is a custom board with a QVGA display. 

Hi Matt

Sorry I did not get a chance to dig into this deeper today. Can you share your register settings/initialization with us for review. Also do you have the LCD PSP drivers and/or LogicPD OMAPL138 board support library package  test examples on LCD to compare and contrast with what you are doing in your setup?

Regards

Mukul

For future readers, in this case the palette load started working (LCD_STAT.PL = 1) after removing a write to the LCDDMA_CTRL.TH_FIFO_READY field and updating the LCDDMA_CTRL.BURST_SIZE field to a proper value.

LCDC Team,

A few more questions came up on the LCDC controller in regards to this problem.  Can you help answer?

1.) PLM setting on LCD raster control.  When we load the palette and set this PLM setting to load palette this works fine.  However, if we then change the PLM setting to load data then we get the sync lost flag error.  The dma address is still pointing to the beginning of the palette and not the beginning of the data.  Does the DMA address need to be updated between the loading of the palette and the loading of the data?  We set up our frame buffer with the palette above the image data.  When we set the mode for load palette + data then the display works better.  We thought we didn't need to load the palette everytime.

2.) How do we clear flags in the status register of the LCDC controller?  Particularly the sync lost flag?  When we write a 1 to it, it does not seem to clear.  Do we have to disable the controller, then write the status registers?

3.) Is there a way to control when the dma engine actually sends data to the frame buffer?  We are seeing artificats in the image and they don't appear to be timing of the LCD, but rather data transfer issues between the dma engine and the actual frame buffer.  Is there any good way to test this theory?

Hi Jason

For 1, what is the intended mode that Matt and team want to use. There are specific usage notes in the LCDC userguide on the PLM setting vs palette loading and what things can be changed on the fly. I hope these are being comprehended

Section 2.5.3

Palette
As explained in the previous section, the pixel data is an index of palette entry (when palette is used). The
number of colors supported is given by 2number of BPP. However, due to a limitation of the
gray-scaler/serializer block, fewer grayscales or colors may be supported.
The PLM field (in RASTER_CTRL) affects the palette loading:
• If PLM is 00b (palette-plus-data mode) or 01b (palette-only mode), the palette is loaded by the DMA engine at the very beginning, which is followed by the loading of pixel data.
• If PLM is 10b (data-only mode), the palette is not loaded. Instead, the DMA engine loads the pixel data immediately.

Section 3.8.6

The 2-bit palette loading field describes how the palette loading behaves when each new frame is loaded
from memory.
• When PLM = 0, the data in the frame buffer represents the palette data and the picture data. Both palette and picture data are loaded.
• When PLM = 1 (palette-only mode), the data in the frame buffer just represents a new palette to be loaded. This data is loaded and placed into the palette. But be sure to turn off the LCD after getting the loading interrupt, or the LCD behavior would be unpredictable.
• When PLM = 2h (data loading mode), the data in the frame buffer only represents the picture data (data-only). This data is then used as an index (in the palette) or sent directly out. This mode assumes the palette was previously loaded. There is no need to keep loading the palette if it is not changing. As a matter of fact, in data-only mode, the BPP is fixed and can not change on the fly since the palette is not loaded at every frame.

JasonHaedt said:

2.) How do we clear flags in the status register of the LCDC controller?  Particularly the sync lost flag?  When we write a 1 to it, it does not seem to clear.  Do we have to disable the controller, then write the status registers?

As per the documentation, you would need to disable the Raster controller is this being done.

Frame synchronization lost. This error happens when the DMA engine attempts to read what it believes to be the first word of the video buffer but it cannot be recognized as such. This could be caused by an invalid frame buffer address or an invalid BPP value (for more details, see Section 2.5.2). The SYNC bit in the LCD_STAT register is set when such an error is detected. This field is cleared by disabling the Raster Controller (clearing the LCDEN bit in the RASTER_CTRLregister).

JasonHaedt said:

3.) Is there a way to control when the dma engine actually sends data to the frame buffer?  We are seeing artificats in the image and they don't appear to be timing of the LCD, but rather data transfer issues between the dma engine and the actual frame buffer.  Is there any good way to test this theory?

What kind of artifacts, any snapshots available. Is there something else going on in the system/test. Is the external memory speed etc set appropriately?