Supporting LCD-6.4-VGA-10 with my WinCE 7 from TI RRS feed

  • Question

  • Hello there,

    I don't know if it fits this forum...

    I'm trying out with my AM3517 EV kit from Texas, to connect this LCD-6.4-VGA-10 screen (640x480).

    The kit is purchased including a smaller LCD 480x272 4,3".

    The platform is supporting bigger displays, but then with DVI interface.

    I'm not getting my parameters correct, to create a new entry for OMAP_LCD_DVI_RES_PARAMS lcd_res_params[...] array.

    Has anyone just tried this, and knows what to tweak?



    Wednesday, February 15, 2012 3:53 PM

All replies

  • what make & model is the 6.4 inch LCD?  Doo you have a datasheet for it, one that shows timing parameters?
    Thursday, February 16, 2012 4:09 PM
  • Hi there,

    Thanks for your reply.

    This is my display: Sharp LCD Display

    I managed to get the bootloader splash image on screen, using this parameter-configuration:

    DISPC_CONTROL: 0x00018109
    DISPC_SIZE_LCD: 0x01df027f
    DISPC_GFX_SIZE: 0x01df027f
    DISPC_TIMING_H: 0x01908931
    DISPC_TIMING_V: 0x02302002
    DISPC_DIVISOR: 0x00010004
    DISPC_CONFIG:  0x00000000
    DISPC_POL_FREQ: 0x00000000
    CM_CLKSEL_DSS: 0x00001009

    This gives me a new display panel in lcd_vga.c looking like this:

    /* OMAP_LCD_640W_480H */
            DISPC_PIXELFORMAT_RGB16,            //pixelFmt;
            640,                                //width;
            480,                                //height;
            0x31,                               //hsw;
            0x89,                               //hfp;
            0x19,                               //hbp;
            0x02,                               //vsw;
            0x20,                               //vfp;
            0x23,                               //vbp;
            0x01,                               //logClkDiv;
            0x04,                               //pixelClkDiv;
            (9 << 0),                           //dss1ClkSel;    
            0,                                  //loadMode;
            0x00000000,                         //polFreq;
            0x00000000,                         //lcdDefaultColor;
            0x00000000,                         //lcdTransColor;
            0x00000000,                         //tvDefaultColor;
            0x00000000,                         //tvTransColor;	

    And by making sure that the DVI interface is not enabled in bootloader code, because a display resolution, other than default, is chosen.. this works.

    But when kernel takes over, the screen goes black again. So the remaining issue is, how to tell kernel about my new display.

    Where and how is that do-able?




    Friday, February 17, 2012 10:52 AM
  • Your BSP must include a display driver, you will need to make similar changes in it.

    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG

    Eurotech Inc.

    Friday, February 17, 2012 1:15 PM
  • Your BSP should be having Display driver. You need to check that your driver is configuring the correct resolution for your new LCD.

    Also see your LCD driver if this is also configuring the correct resolution as per new LCD. (Lcd_vga.c source file)

    There is a lcd.h file, check for the correct configuration there. This is included in dssai.cpp (display driver) source.

    Hope this may help.

    All the best.


    Senior Design Engineer T.E.S Electroni Solutions (Bangalore-India)

    • Proposed as answer by Misbah Khan Thursday, February 23, 2012 5:53 AM
    Friday, February 17, 2012 2:05 PM
  • The display is showing splash screen and desktop image/application screen, but the touch is not working.

    Regarding configuration of parameters, if you exchange the new display panel data-combination with the default (OMAP_LCD_DEFAULT) data in lcd_vga.c then this will work. I haven't been able to find any other places in kernel code, where I can modify regarding the display driver. Bootloader and kernel simply share the display parameters, set in lcd_vga.c.

    The reason why the touch is not working, is still an issue.

    It might have something to do with setting register configuration of my TSC2004 touch driver correctly... according to new display.

    The TSC2004 is onboard, and therefore still the same wince driver... and the new display is pin-compatible with the external lcd-connector... as it is purchased the same place as the ev-kit and the original display.



    Wednesday, February 22, 2012 2:58 PM
  • so the display is working acceptably now after Windows boots up, is that correct?

    and regarding touchscreen, is it completely unresponsive or just not accurate, or cannot be calibrated at all, or maybe something else?  what is the make and model of the touchscreen?

    would you mind stating what vendor you bought the eval kit from?  I might be able to provide better assistance, as I have recently worked on integrating an OMAP-based SOM incl. the same Sharp LCD you mention above, and we were using a 4-wire resistive touchscreen as well.

    Wednesday, February 22, 2012 6:20 PM
  • 1. As per the new display resolution your touch screen driver should be reconfigured. check if "TouchDriverCalibrationPointGet()" function is accessing correct display width & height ?

    2. Other functions such as "DdsiTouchPanelGetPoint()" , "PddGetTouchData()" should be also accessing correct screen width and height.

    3. Include/enable debug messages in the touch driver and see if you are getting touch event (Pen interrupt and able to read the coordinates) .

    --- Misbah

    Senior Design Engineer T.E.S Electroni Solutions (Bangalore-India)

    Thursday, February 23, 2012 5:53 AM
  • I'm using TI's evaluation kit for AM3517.

    The AM3517-SOM is provided by and the new display is purchased via logicpd as well.

    I have no more detailed info on the resistive touchpanel itself, but it is 4 wire as well.

    At the moment, I'm experiencing a strange behaviour. If I run the wince calibration software for the screen, during boot, there is no reponse. If I bypass the calibration, and use the default calibration data in registry instead, I finish my boot and I get response when pressing. If I press one time it register and samples, but it seems like the touchcontroller (TSC2004) does not register when I release the press. The wince touchdriver keeps continuously sampling touch data. By looking at the sampled data-coordinates though, it is following my movement on the screen so the electrical connection is ok.

    Now it must be the configuration of the touchcontroller itself, which apparently is different with the new touchpanel compared to the original one. I'm looking into the datasheet for the touchdriver now, to see what can be tweaked. Maybe it has something to do with the touchpanel resistance range.

    Thanks for replying..


    Thursday, February 23, 2012 10:42 AM
  • I did have suggested  you some points in my last reply, but you didnt responded.

    AFAIK TSC2004 is i2c based touch controller which does not require any configuration.

    You need to check with sampling rate, debounce and polling duration. Along with my previous suggessions to you.

    --- Misbah

    Senior Design Engineer T.E.S Electroni Solutions (Bangalore-India)

    Thursday, February 23, 2012 10:54 AM
  • Hello Misbah,

    Thanks for replying.

    When you say that the touchscreen driver needs to be reconfigured, and i.e. '..."PddGetTouchData()" should be also accessing correct screen width and height..' I'm not sure what you mean and where to look.

    I'm getting readings from the touch, and the coordinates seem to be correct. The problem is that the touch controller doesn't register my touch-release and keeps sampling and interrupting my host to read touch-data.

    '217393 PID:400002 TID:2e00026 Invalid touch state transition from flags 0 to flags 1019.

    217403 PID:400002 TID:3bd006e PDDGetTouchData: i=3, pxAvg=386, pyAvg=461

    217405 PID:400002 TID:3bd006e X(0x182) Y(0x1CD)'

    This is an example of my debug readings, and I keep getting the 'invalid touch state transition...' which I don't get when using the original display. I can't locate this debug message and where it comes from.

    When I tap the screen first time, the host gets interrupted and coordinates get sampled. The problem is that it keeps on sampling with some value deviation like if it was some noise. If I press again and move my finger around on the screen, I get my readings updated correctly, but when I release again it changes back to its very first touch reading and again, continuously samples the point with some deviation. So somehow it recoqnizes my press and release there, but anyways keeps on sampling from the original point. Strange!

    I'm still trying out with some values, like you mentioned.. but no luck so far.


    Thursday, February 23, 2012 1:17 PM
  • /******************************************************************************

    ****** Example code for you when i mean correct height & weidth confiruration is essential.


    //  DdsiTouchPanelGetPoint
        TOUCH_PANEL_SAMPLE_FLAGS *pTipStateFlags,
        INT *pUncalX,
        INT *pUncalY
        // MDD needs us to hold on to last valid sample and previous pen state.
        static USHORT usLastFilteredX        = 0;    // This holds the previous X sample
        static USHORT usLastFilteredY        = 0;    // This holds the previous Y sample
        static USHORT usSavedFilteredX      = 0;    // This holds the last reported X sample
        static USHORT usSavedFilteredY      = 0;    // This holds the last reported Y sample
        static BOOL bPrevReportedPenDown    = FALSE;
        static DWORD DelayedSampleCount        = 0;

        BOOL bReportedPenDown                 = FALSE; // This indicates if we are reporting pen down to the mdd
        BOOL bActualPenDown                 = FALSE; // This indicates if the pen is actually down, whether we report or not
        UINT32 xpos;
        UINT32 ypos;

        DEBUGMSG(ZONE_FUNCTION&&ZONE_SAMPLES, (TEXT("DdsiTouchPanelGetPoint+\r\n")));

        // By default, any sample returned will be ignored.
        *pTipStateFlags = TouchSampleIgnore;
        // Check if pen data are available If so, get the data.
        // Note that we always return data from the previous sample to avoid returning data nearest
        // the point where the pen is going up.  Data during light touches is not accurate and should
        // normally be rejected.  Without the ability to do pressure measurement, we are limited to
        // rejecting points near the beginning and end of the pen down period.
        bActualPenDown = PddGetTouchIntPinState();
        if (bActualPenDown == TRUE)
            PddGetTouchData(&xpos, &ypos);
            if (DelayedSampleCount > s_TouchDevice.nInitialSamplesDropped)
                // Indicate pen down so we can return valid data.
                bReportedPenDown = TRUE;


        // Check if we have valid data to report to the MDD.
        if (bReportedPenDown)
            // Return the valid pen data.  Note that this data was actually obtained on the
            // previous sample
            *pUncalX = usLastFilteredX;
            *pUncalY = usLastFilteredY;

        // Save the data that we returned.
        // This will also be returned on penup to help avoid returning data obtained during
        // a light press
        usSavedFilteredX = usLastFilteredX;
        usSavedFilteredY = usLastFilteredY;

        //DEBUGMSG(ZONE_SAMPLES, ( TEXT( "X(0x%X) Y(0x%X)\r\n" ), *pUncalX, *pUncalY ) );

            // Store reported pen state.
            *pTipStateFlags = TouchSampleDownFlag | TouchSampleValidFlag;
            tch_pdwn_flag = TRUE;
        else    // Otherwise, assume pen is up.
            // Check if previously down and valid.
            if ( (bPrevReportedPenDown) && (tch_data == 0)&& (tch_pdwn_flag))

                    tch_pdwn_flag = FALSE;
                    //RETAILMSG(0, ( TEXT( "Pen Up!\r\n" ) ) );

                            // Use the last valid sample. MDD needs an up with valid data.
                    *pUncalX = usSavedFilteredX;
                    *pUncalY = usSavedFilteredY;

                    *pTipStateFlags = TouchSampleValidFlag;
                    //RETAILMSG(0, ( TEXT( "Point: (%d,%d)\r\n" ), *pUncalX, *pUncalY ) );


        // Save current reported pen state.
        bPrevReportedPenDown = bReportedPenDown;

        // Set up interrupt/timer for next sample
        if (bActualPenDown)
            // Pen down so set MDD timeout for polling mode.
            gdwTouchIstTimeout = 1000 / s_TouchDevice.nSampleRate;
            // Save point measured during this sample so it can be reported on the next sample

            if((xpos < DISPLAY_WIDTH) &&(ypos < DISPLAY_HEIGHT))//Condition added for capacitive touch(MAGIK)
            usLastFilteredX = xpos ;
            usLastFilteredY = ypos;

            // Reset the delayed sample counter
            DelayedSampleCount = 0;
            usLastFilteredX = 0;
            usLastFilteredY = 0;

            // Pen up so set MDD timeout for interrupt mode.
            gdwTouchIstTimeout = INFINITE;
            //RETAILMSG(1,(TEXT("******TOUCH:Interrupt******* \r\n")));
            // Set the proper state for the next interrupt.
            InterruptDone( gIntrTouch );

        DEBUGMSG(ZONE_FUNCTION&&ZONE_SAMPLES, (TEXT("DdsiTouchPanelGetPoint+\r\n")));


    //  PddGetTouchData

        UINT32 * xpos,
        UINT32 * ypos

        INT pxAvg = 0, pyAvg = 0;
        DWORD read_ret=0;

        DEBUGMSG(ZONE_FUNCTION, ( TEXT("PddGetTouchData+\r\n" )) );

        UCHAR reg_values[28];
        if(s_TouchDevice.hI2C ==NULL)
            RETAILMSG(1,(TEXT("Touch:Invalid Handle\r\n")));

            read_ret = I2CRead(s_TouchDevice.hI2C, TSC_SA, &reg_values, 28);

            //RETAILMSG(1,(TEXT("Touch:Read count-%d\r\n"),read_ret));
            if( read_ret!= 28)
                RETAILMSG(1,(TEXT("Touch:Unable fetch the data\r\n")));
                //return FALSE;
            pxAvg = ((reg_values[0]&0xff)<<8)|(reg_values[1]);
            pyAvg = ((reg_values[2]&0xff)<<8)|(reg_values[3]);

            pxAvg = (pxAvg * DISPLAY_WIDTH)/2048;
              pyAvg = (pyAvg * DISPLAY_HEIGHT)/2048;


        //RETAILMSG(1,(TEXT("Touch:YPos- %d\r\n"),pyAvg));
        //RETAILMSG(1,(TEXT("Touch:finger count- %d  \r\n"),reg_values[9]));
        //Assign Finger count value  (MGM)
        tch_data = reg_values[9];
        *xpos = pxAvg;
        *ypos = pyAvg;
        //Sleep(5);//sleep for 5ms

        // Possibly Pen Up, give pen status detection a chance to debounce
        if(pyAvg == 0 && s_TouchDevice.PenUpDebounceMS) Sleep(s_TouchDevice.PenUpDebounceMS);

        DEBUGMSG(ZONE_FUNCTION, ( TEXT("PddGetTouchData-\r\n" )) );

        return TRUE;

    How are you reading the pen down and Pen Up status ?

    When you get pen up status you should do InterrupDone and again block for next interrupt.

    What are you reading via i2c during the strange period you mentioned? check this value against the data sheet of TSC2004.

    --- Misbah


    Senior Design Engineer T.E.S Electroni Solutions (Bangalore-India)

    Thursday, February 23, 2012 2:06 PM
  • I agree with what Misbah has written.  We used a different CPU but that driver code above looks very very close to what we started with on my project.  First, turn on more debug messages, confirm that the X and Y size of the screen are correct as presented to the driver.  Then, check to see if the driver is correctly recognizing pen UP and pen DOWN.    Notice that you can adjust the sample rate and the debounce time; these are probably set up via the registry at HKLM\HardwareDEVICEMAP\TOUCH. 

    Our experience is that the system was highly sensitive to changes in the baud rate, pen sensitivity, and other factors.  Our driver offered either a "window" filter or a "median" filter, and we gave up trying to get the window filter to work well with our TS hardware.

    Also, we had a couple of different brands of hardware.  One TS was a 3m/MicroTouch, the other was a HanTouch.  The HanTouch is a more recent model and it worked well with our tweaked driver, but we were simply unable to find a combination of driver registry settings that gave acceptable performance with the 3m/MicroTouch TS.

    So, my recommendations are to get at least two different TS if you can, so you can compare them.  Maybe one is markedly better for you.  Next, plan to spend some time tweaking and testing different touch driver settings via the registry.  Start with changing the baud rate, if that's one of the settings, and see if bumping it up or down gets things working well enough.

    good luck.

    Thursday, February 23, 2012 3:17 PM
  • Hey there both of you,

    Thanks for your time and help.

    Just to answer some of this, my PddGetTouchData looks like this, in essential:

            for( i = 0; i < MAX_PTS; i++ )
                PDDGetControllerData(COMMAND_CNV_SELECTXY, tempdata); 
                px = tempdata[0];
                py = tempdata[1];
                if (i == 0)
                    pxAvg = px;
                    pyAvg = py;
                    iAvg = 1;
                else if  ((((pxAvg >= px)  &  ((UINT16)(px+DELTA) >= pxAvg)) | ((px > pxAvg)  &  ((UINT16)(pxAvg+DELTA) > px))) &
                              (((pyAvg >=py)  &  ((UINT16)(py+DELTA) >=pyAvg)) | ((py > pyAvg)  &  ((UINT16)(pyAvg+DELTA) > py))) )
                    pxAvg = (pxAvg +px)/2;
                    pyAvg = (pyAvg +py)/2;
        }while(iAvg < MAX_PTS);

    Where DELTA is set to 30!
    For the DdsiTouchPanelGetPoint function, I only find the prototype declaration in tchddsi.h. No source.

    The status of the pen, if it is up or down, is stated by reading the status bit in configuration register 0 in touch-controller. See PDDTouchPanelGetPoint(..), which is called from the PDDTouchIST.

    Maybe our source reference is of different version.

    But I need to correct/modify my earlier post. The first touch is registered correctly and the coordinates match. When I release, it keeps on sampling and the sample data point is always somewhat the center of the screen. So the touch-controller never register a release, and therefore the status check for touch-release always returns TRUE, i.e.

    	// read PSM bit in CFG0
    	ucCommand = 0x80;		// MSB D7 is always set to 1
    	I2CWrite(s_TouchDevice.hI2C, I2C_SUBADDRESS_MODE_0, &ucCommand, sizeof(ucCommand));
    	ucCommand = (CFG0_REG << 3)| COMMAND_ENABLE_READ;
    	I2CWrite(s_TouchDevice.hI2C, I2C_SUBADDRESS_MODE_0, &ucCommand, sizeof(ucCommand));
    	I2CRead(s_TouchDevice.hI2C, I2C_SUBADDRESS_MODE_0, ucData, 2*sizeof(UCHAR));
    	return ((ucData[0] & PINTS1) == PINTS1 ? TRUE : FALSE);

    But thanks for your help.


    Thursday, February 23, 2012 3:48 PM
  • Looks like some issue is with the H/W.

    In the S/W may be you can try resetting the TSC2004 during boot (boot loader). Look at the data sheet it tells how to reset.

    This type of event is called ghost event, most this is associated with H/W issue.

    --- Misbah

    Senior Design Engineer T.E.S Electroni Solutions (Bangalore-India)

    Friday, February 24, 2012 1:52 PM
  • I am working on am3517. From the U-Boot binary, I need to separate the splash screen image (in a raw binary format) from NAND to the framebuffer.

    Any advice is appreciated.


    Monday, February 27, 2012 11:44 AM
  • Can you open a New thread and post your quarry.

    Please explain the things more clearly  "I need to separate the splash screen image (in a raw binary format) from NAND to the framebuffer"

    How are you booting your device (SD Boot, NAND boot, ethernet boot etc) ?

    At what location your splash screen image is in NAND ?

    You want to "separate" means what ??

    --- Misbah 

    Senior Design Engineer T.E.S Electroni Solutions (Bangalore-India)

    Monday, February 27, 2012 1:02 PM