1. Hi,
2. We are using the TI Sitara AM37X Evaluation Module (EVM) Sitara from Mistral for developing a handheld device.The LCD in the kit has been replaced by a 24bit 4.3 inch NEC LCD(NL4827HC19-05B). The driver modifications are as follows:
1.The timing parameters were changed in the file lcd_vga.c
{ /*NEC_LCD_480H_272W */
DISPC_PIXELFORMAT_RGB16, //pixelFmt;
480, //width;
272, //height;
40, //hsw;
1, //hfp;
1, //hbp;
1, //vsw;
0, //vfp;
0, //vbp;
1, //logClkDiv;
9, //pixelClkDiv;
(11 << 0), //dss1ClkSel;
0, //loadMode;
(DISPC_POL_FREQ_IVS | DISPC_POL_FREQ_IHS | DISPC_POL_FREQ_ONOFF),//polFreq;
0x00000000, //lcdDefaultColor;
0x00000000, //lcdTransColor;
0x00000000, //tvDefaultColor;
0x00000000, //tvTransColor;
},
2. changed the output format from 18 to 24 bit
OUTREG32( &g_pDispRegs->DISPC_CONTROL,
DISPC_CONTROL_GPOUT1 |
DISPC_CONTROL_GPOUT0 |
DISPC_CONTROL_TFTDATALINES_24 |
// DISPC_CONTROL_TFTDATALINES_18 |
DISPC_CONTROL_STNTFT
);
3.changed the bitmask in file omap_ddge.cpp
case OMAP_DSS_PIXELFORMAT_RGB16:
*pAlphaBitMask = 0xff000000;
*pRBitMask = 0x00ff0000;
*pGBitMask = 0x0000ff00;
*pBBitMask = 0x000000ff;
bResult = TRUE;
break;
However after booting WinCE the display shows flicker. Any help or pointers to solve the issue is highly appreciated.
Thanks,
Jithendran
http://www.nestgroup.net/
3. The data sheet of the LCD available in the following link. minidevs.googlecode.com/files/NEC-NL4827HC19.pdf
Pl. have a look at your timing parameters again. Just quickly looking through the data sheet, your horizontal and vertical porch settings seem to be violating the min requirements of your panel
Atul
Hi Atul,
Thanks for the reply.After correcting the LCD timing parameters the display works perfectly.However the Win CE 6.0 CETK tests fails.
Apart from the changes in timing parameters the modifications for Screen rotation is also implemented in the code base as described below
1.Registry change-(“C:\WINCE600\PLATFORM\EVM_OMAP3530\SRC\DRIVERS\DISPLAY\DSS\DSS.reg“)
[HKEY_LOCAL_MACHINE\System\GDI\Drivers]
"Angle"=dword:90
2. “omap_ddgpe.cpp” function - OMAPDDGPE::OMAPDDGPE())
Both DDraw tests and GDI tests fails as attached in the log.Please help me out as whatmight be the reasons that cause the test to fail?
0576.DirectDraw_Test.log
3021.DirectDraw_Performance_Test.log
// Default to angle 90
m_iGraphicsRotate = DMDO_90;
g_Globals.m_dwRotationAngle = DMDO_90;
dwWidth = m_pDisplayContr->GetLCDHeight();
dwHeight = m_pDisplayContr->GetLCDWidth();
Jithendran,
As such the failure seems to be due to a failure in DirectDraw.GetObject.
I conclude this from the DDraw log which reports an error
"### Get global DDraw Object [FILE: ddtestkit_modes.cpp LINE: 62]" and from the test source present at:
C:\WINCE600\PRIVATE\TEST\MULTIMEDIA\DIRECTX\DDRAW\TESTKIT\DDRAWTK
Does the test pass if the default angle is 0? I am guessing that the angle should not matter but that just might rule out this reason.
Also, were you able to get some reason for the failure from the GDI test log? The attachments in your post were for DDraw and DDraw_performance.
regards,
Aparna
Please click Verify Answer button if this response answers your question.
Also, another data point to check might be the VRFB enabled/disabled setting and if a change to that, modifies the result of the CETK test.
Hi Aparna,
Thanks for the reply.
CETK tests were run after enabling VRFB based screen rotation .All the TC’s failed.
The lcd pixel format used is OMAP_DSS_PIXELFORMAT_RGB16
The bit masks are *pAlphaBitMask = 0x00000000; // *pAlphaBitMask = 0x00000000;
*pRBitMask = 0x00f80000; // *pRBitMask = 0x00ff0000;
*pGBitMask = 0x0000fc00; // *pGBitMask = 0x0000ff00;
*pBBitMask = 0x000000f8; // *pBBitMask = 0x000000ff;
Output format In lcd_vga.c OUTREG32( &g_pDispRegs->DISPC_CONTROL,
DISPC_CONTROL_TFTDATALINES_24 | // DISPC_CONTROL_TFTDATALINES_18
Can we conclude that the CETK tests always fails with screen rotation enabled?
Please find attached the logs.
2146.vrfb.txt
I used the "do rotate 90" command on the baseline code to rotate the screen. The GDI and Ddraw tests pass. Is it possible that there is some other window open on the foreground while you are executing this test? If so, could you minimize or close it and try the test again? Typically, the failure that you are seeing now is related to an unexpected window present in the foreground. I can recreate a similar failure if I open the keypad from the desktop and then run the GDI cetk test.
There is no window open on the foreground. We also tested without any screen rotation as described below
(16pixel format and 24 bit output )
The test suite runs successfully on the sharp LCD that ships with the Mistral EVK.However the test suite fails when the sharp LCD is replaced by 24 bit NEC LCD but the display works perfect(MFC/.NET GUI ).Also attached the log .
2843.log_NEC.txt
Hi Jithendran,
Could you try to set the surface type in your test command-line to reflect the 24-bit format you are using? List of types of surfaces can be found at the msdn link below. Another suggestion would be to turn on manual verification from the command-line (one of the parameters mentioned on the same msdn page) and see how it goes. If these ideas do not help in resolving/debugging the issue, you might want to check with microsoft about this cetk test. Maybe, the test assumes some default setting in the display hardware.
http://msdn.microsoft.com/en-US/library/ee505759%28v=WinEmbedded.60%29.aspx
Regards,
To specify 90 degree rotation, you have to set the Angle registry key to 1 and not 90. See the note in dss.reg.
; sets initial screen rotation ; use 0 for 0 degree, 1 for 90 degree, 2 for 180 degree and 4 for 270 degree ; Note: Rotation should not be used with the flat frame buffer, memory/bus bandwidth may ; be exceeded by display scanning requirements causing display to flicker and/or lock up. "Angle" = dword:0
Please undo the changes in OMAPDDGPE, set the registry correctly and run your tests again. Also, just to be clear in your following quote:
(16pixel format and 24 bit output ) The test suite runs successfully on the sharp LCD that ships with the Mistral EVK. However the test suite fails when the sharp LCD is replaced by 24 bit NEC LCD but the display works perfect(MFC/.NET GUI )
The test suite runs successfully on the sharp LCD that ships with the Mistral EVK. However the test suite fails when the sharp LCD is replaced by 24 bit NEC LCD but the display works perfect(MFC/.NET GUI )
Does this mean that with rotation angle 0 and your 24 bit NEC LCD, the CETK tests fail or is this with rotation angle 90 and 24 bit NEC LCD?
-Madhvi
Please click Verify Answer button if this response answers your question. For updated information on TI WINCE BSP, please check out the WinCE Handbook.
The DVI mode supported by the BSP uses the 24bpp format. I could run the GDI tests successfully using 1280x720 display mode and without specifying any display format options in the command-line. Command-line used was tux -o -d ddi_test.dll -c "/OutputBitmaps".
So, we know for sure that there is no issue with the 24bpp mode with the driver or with the CETK test suite.
A small correction in the command-line in previous response. Test dll would be gdiapi.dll and not ddi_test.dll as mentioned.
Hi Aprana/Madhavi,
Thanks for the help and suggestions.But couldn't resolve the issue .
Please find the various options tried out and the results without any screen rotation consolidated below below.
Any changes to be done for DISPC_GFX_ATTRIBUTES ?.
------------------------------------------------------------------------
From your experiments, it seems like there is some connection issue between the AM37x and your LCD panel. On our EVM, we have tested case 1 (LCD) and 2 (DVI) and both CETK results and LCD appearance are good. Looking at the case 2 and 4 on your h/w, suggests that if you try case (2) with Pixel Format = RGB16, Output Format = 24, Mask=555, then your LCD would be good but CETK would obviously fail due to wrong mask.
All we can suggest to you is to check the data lines between the DSS out and your LCD panel.
FYI - we don't validate RGB32 pixel format on our setup and are not sure what performance impact it may have.
Hi Jithendran and Atul,
I have an OMAP3530/WinCE/BSP_A8_01_01. I am trying to to the same - modifying the driver to support 24-bit LCD - but without success. I make the same changes as Jithendran did but the color is still all wrong.
I have some questions for both of you. Why is pixelFmt still DISPC_PIXELFORMAT_RGB16 even though you are using 24-bit? Should it be DISPC_PIXELFORMAT_RGB32?
I also tried DISPC_PIXELFORMAT_RGB32 but did not get it right either. Are there more changes I need to do in the display drivers?
I appreciate any help that you can give me.
Luan
Yes you "should" use pixel format RGB32 although RGB16 should work as well (you will just have less bits for each color). Since we don't have the HW, you will have to debug the issue yourself - fill frame buffer with solid colors (red, green, blue one at a time) and probe LCD color lines to check if appropriate ones are changing.