This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LCD display Split issue on TIVA C board (1280 x 320 resolution)

We are trying to display an Image on CDTECH S088WX03 display panel interfaced to TIVAC LCD controller through LVDS.  We are trying to display an RGB image with resolution 1280 x 320. We have taken "raster_example" from the TivaWare_C_Series-2.1.0.12573 TI RTOS lcd peripheral examples as reference to create this code. We are reading the framebuffer from SDRAM through EPI interface(SDRAM base address:0x60000000).The code uses GRLIB graphics library to prepare and draw the frame buffers.

The timing parameters used as specified in the display datasheet is as below:

const tRasterDisplayInfo g_scdtech1280x320x60Hz =
{
    "1280x480 at 60MHz on CDTECH",
    59000000,
    SYSCTL_CFG_VCO_480,
    120000000,
    {
        (RASTER_TIMING_ACTIVE_HIGH_PIXCLK |
        RASTER_TIMING_SYNCS_ON_RISING_PIXCLK |
        RASTER_TIMING_ACTIVE_LOW_HSYNC |
        RASTER_TIMING_ACTIVE_LOW_VSYNC |
        RASTER_TIMING_ACTIVE_HIGH_OE),
        1280, 320,
        22,72,10,
        8,8,10,
        0
    },
    InitCdTech
};

With this, we are able to see the TI logo, but the frame displayes as splitted. i.e. the same frame repeats 5 times on the display as in the attachment.

Could anyone give some pointers to fix this issue.

  • Hello Prashanth,

    Are you using the same logic as the one in "raster_example.c" to draw the image in the center of the screen? If yes, then some how the API "GrContextDpyWidthGet" is returning a wrong value, but that still does not explain why 5 different logos are being drawn.

    Can you confirm if the parameters being passed to the function GrImageDraw have correct values? Any other debug information that might be useful?

    Thanks,
    Sai
  • Usually - but not always - when dealing w/such issue - it proves best to start w/single color - and the simplest possible image.

    Firm/I find that a 16 pixel "cross-hair" proves effective - and we strive to place one @ upper left and then bottom right of the screen. Success there will establish that your set-up pixel heights/widths are proper - and if not - the simplicity of our suggested image will enable a quicker & easier diagnosis of the illegal screen writes...

    KISS - aka, "Proceed by Refinement" always speeds, eases, enhances such quest...
  • Hello Sai,

    Thanks for your reply.

    We are using the same logic as in "raster_example.c". Only change we have done is adding the display timing strucutre for the CDTECH display(with the values mentioned in the query). And updated the following macros for our required image resolution.

    RASTER_WIDTH = 1280;

    RASTER_HEIGHT = 320;

    I checked the value returned by GrContextDpyWidthGet(), it return the width as 1280.

    And, the parameters being passed to GrImageDraw() for the example logo is as below:

    ui32X = 600;

    ui32Y = 122;

    Since the example tries to display this logo on the center of the screen, I hope the x and y offsets passed above is also fine.

  • Hello Prashanth,

    Those values are correct. So the application is sending the correct values, but somehow the driver is interpreting these values differently.

    Since this display is not supported by TivaWare, the user is expected to write the driver for this display panel. Did you develop a driver (on the lines of "grlib_raster_driver_xxx.c/.h" files) for this panel? If yes then did you test the driver to check if it is working as expected?

    The recommendations provided by cb1 can be used to test the driver quickly. To test more extensively, the example "grlib_driver_test" located in the folder "examples/boards/dk-tm4c129x" can be used. This example is configured to operate with the DK-TM4C129X display panel but can be configured to work with other displays.

    Thanks,
    Sai
  • Stellaris Sai said:
    The recommendations provided by cb1 can be used to test the driver quickly.

    Thank you, Sai.   Having been long in the display biz - the adoption of, "Proceed by Refinement" - aka "KISS" - is most always - the shortest & best path to success.

    Kitchen sink approach (all at once) as reported by poster - insures, "Lack of full and/or proper understanding" and leads to guess, hunches (even witchcraft).

    Short, small, highly focused steps build understanding - cookbook/hodge-podge - too often (always!) yields (famed) "Does not work!"