• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 723 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DM355 VPBE LCD Colour test bars OK, real video not present

SteveG10854
Intellectual 510 points

We have an 800x600 LCD connected through our own adapter to DC5 of the DM355 EVM. File logicpd_encoder.c has been modified to set the appropriate values:
 
if_type:    PRGB   
Interlaced: 0   
xres:       800   
yres:       600   
fps:        60   
leftmarg:   0   
rghtmarg:   256   
upmarg:     0   
lowmarg:    28   
hsyn len:   9   
vsyn len:   9   
flags:      0= hsyn -ve, vsyn -ve 

If I add a line into function enableDigitalOutput() of file davinci_platform.c, that sets the VDPRO CBMD bit to enable the colour bars test, I get excellent bars across the whole display in the correct order (left to right - white, yellow, cyan, green, magenta, red, blue, black). The Dot clock, LCD_OE, HSYNC, VSYNC, C and Y pins scope out good.

Removing this line of test code so as to view normal video, I get a single green rectangle based at the top right of the screen, extending about 3/4 of the way right and down.

Scoping the pins, the clock, LCD_OE, H and V syncs look good. However:
  VDOUT_C5 is a 25.6KHz wave with a high period of 23.6uSec
  VDOUT_Y2 is a 25.6KHz wave with a high period of 29.6uSec
  No other Y or C pin shows any activity at all.

I expected all the lines to be wiggling as long as there was something to display, and didn't expect C5 and Y2 to be outputting regular waves.

I'm guessing the green rectangle is caused by the remaining activity on the C5 and Y2 pins, as this represents a Green data line.

I modified davinci_platform.c to log all writes to the VPBE registers, the resulting register values are (a=address, d=hexdata):

Reg a:0x01C72784 d:0000 // PCR …… THOUGH THIS ADDRESS IS A REGISTER IN THE DM644X!!
Reg a:0x01C70518 d:057C // DRGBX1
Reg a:0x01C70430 d:0000 // HSDLY
Reg a:0x01C70434 d:0000 // VSDLY
Reg a:0x01C70528 d:0000 // VSTARTA
Reg a:0x01C4002C d:E21A6B6 // DM355_VDAC_CONFIG

Reg a:0x01C70438 d:0000 // YCCCTL
Reg a:0x01C704F4 d:0000 // DACSEL
Reg a:0x01C70408 d:0100 // VDPRO  // has a bit set because we have colour bars test on

Reg a:0x01C40044 d:0018 // SYS_VPSS_CLKCTL
Reg a:0x01C7052C d:0000 // OSDCLK0
Reg a:0x01C70530 d:0001 // OSDCLK1
Reg a:0x01C704DC d:0000 // CBVS
Reg a:0x01C70540 d:0011 // CLKCTL

Reg a:0x01C70240 d:0000 // OSD_BASEPX
Reg a:0x01C70244 d:0000 // OSD_BASEPY
Reg a:0x01C70404 d:2000 // VIDCTL
Reg a:0x01C70464 d:0800 // DCLKCTL
Reg a:0x01C70468 d:0001 // DCLKPTN0
Reg a:0x01C70410 d:0009 // HSPLS
Reg a:0x01C7041C d:0000 // HSTART
Reg a:0x01C70420 d:0320 // HVALID
Reg a:0x01C70418 d:041F // HINT
Reg a:0x01C70414 d:0009 // VSPLS
Reg a:0x01C70428 d:0000 // VSTART
Reg a:0x01C7042C d:0258 // VVALID
Reg a:0x01C70424 d:0274 // VINT
Reg a:0x01C7040C d:000F // SYNCCTL
Reg a:0x01C70400 d:2011 // VMOD
Reg a:0x01C7044C d:0001 // LCDOUT

Could you tell me please, do these registers look OK?

Also, this is running on the DVEVM, on which at the end of bootup the DVEVM displays the usual bitmap graphic of the 'remote control' as a prompt to the user for running the video demonstrations. This shows OK as composite (ie. without switching to the LCD). Would we expect this graphic to be shown OK on the LCD when LCD is selected, without any other changes? What we are doing is selecting the LCD in bootargs, and expecting the LCD to show the 'remote control' graphic at the end of bootup.

Many thanks.

  • 0
    TI__Mastermind 37340 points

    What is the source of your video input, composite input? 

    One thing to keep in mind is that pixel clock (27 MHz on EVM as required by NTSC) and the relationship

        pixel clock = resolution (including blanking) x refresh rate.

    For composite NTSC (720x480) video output via analog DACs in DM355 EVM, you have the required pixel clock.  If you are trying to do 800 x 600 on LCD output, you must figure out the refresh rate you will be getting given you have a fixed 27 MHz pixel clock on EVM and an 809x609 resolution(need to add blanking to get true resolution).  Then you need to ensure your display supports this resolution; for example, if your display supports this resolution at say 25 MHz, 45 MHz, and 60 MHz and your refresh rate happens to be 30 MHz, then you may see odd things on your display.  The final challenge is synching your input video data to your output video data.  Your NTSC input video is coming in at 30 frames per second (refresh rate), since the output resolution is different, then this means that your output refresh rate is different.  Your user lavel application needs to manage this difference if refresh rates, otherwise, it may be displaying invalid data.  To overcome this, our demos assume same resolution and refresh rate for both video input and output and when you choose a different output resolution (which can only be smaller than input in our demos), it puts it in a box inside the full output resolution which is equal to the input.  If you have modifies our demo and are using true different output resolution, you may need to adjust for proper buffer pointer offsets; otherwise, you may be seeing blanking data (could explain why pixel values do not change).  Hope this helps.

  • 0 in reply to Juan Gonzales
    Intellectual 510 points

    I'm not actually feeding any video input into the system yet, or running the demos, just trying to get the normal end of boot graphic of the remote control showing on the 800x600 LCD.

    And got a bit further with this.....

    Using the bootargs to select LCD output at bootup, all I get is the green rectangle described above. I have several debug printk in the LCD driver to show the register values so I know when it's being executed,
    and it does get executed at bootup.

    But here's something that nearly works:

    Bootup with bootargs selecting PAL or NTSC Composite (ie. default bootargs).

    After logging in, use the command
       echo "LCD" > /sys/class/davinci_display/ch0/output
    ... to switch to LCD output.

    The same debugs get shown, so I know the driver is being executed again.

    But this time, I do get some output on the LCD:


    The picture shows what happens if initially selecting NTSC composite through bootargs, then selecting LCD afterwards through the "echo" command.

    The output is smaller than expected, just under half the screen, and it flickers and jumps (just like it was interlaced??).

    The output height is also related to whether NTSC or PAL composite is selected first. If PAL is selected, the height of the shown image is a bit bigger (possibly because there are more scan lines in a composite PAL frame).

    This suggests there is some part of the system that is configured by selecting composite PAL and NTSC first that is not being configured when booting straight into LCD output, and LCD inherits this configuration when it is selected later. Or that there is something done by the "echo" command which sets up some other configuration in addition to that done by calling the LCD driver.

    It also suggests there is some relationship between the composite selection and LCD - I assumed once LCD is selected that the composite settings were not relevant?

    We've checked the LCD hardware signals and they are indeed 800 pixels by 600 lines, and in the bottom half of the lines there is no data pin activity. So it would appear that the back end is taking video from a buffer and outputting faithfully what it sees in there, but whatever puts the data into this buffer might still be putting it in there in composite format (could explain the green screen if there is nothing configured to put the data into the buffer) - could you tell me please where in the driver source is the buffer written with either composite or RGB format?

    Maybe someone has seen this 'half height' picture before, is it because some other part of the system is still assuming composite, and maybe someone could help with the cause and cure please? Many thanks.

  • 0 in reply to SteveG10854
    TI__Mastermind 41665 points

    SteveG said:
    It also suggests there is some relationship between the composite selection and LCD - I assumed once LCD is selected that the composite settings were not relevant?

    They should be independent from the perspective of how the driver configures the hardware, however the hardware itself is the same for all video outputs, that is configurations to the LCD output would impact the composite output and vice versa. This being said if your LCD requires some setting that is inadvertently configured by the NTSC composite output setting than you may want to look down that path. In particular if you take a dump of the register settings which are working for you, and those which are not and do a comparison that may lead to the bit settings that are missing from your configuration.

    SteveG said:
    could you tell me please where in the driver source is the buffer written with either composite or RGB format?

    The format of the buffer itself is independent of the display output, because the OSD hardware will convert for you, essentially the buffer format is dependent on the OSD window you are using and that OSD window's configuration versus your actual output. You configure the output color format by selecting a particular output, i.e. LCD, composite, etc, and since the colors seem to look right on your display you should be set there.

  • 0 in reply to SteveG10854
    Intellectual 300 points

    Steve, 

    The half height video indicates that you are looking at an interlaced frame on a progressive display.  You need to explicitly set varInfo.vmode = FB_VMODE_NONINTERLACED in the demo programs.

  • 0 in reply to Vim Venture
    Intellectual 510 points

    Thanks guys. Still can’t get this going. I substituted the file startup_pal.png with a bitmap (720x567) I drew up containing some test shapes to give me better idea of what's going where on screen, so this gets displayed by the TI app at bootup instead of the graphic of the remote control. After booting into Composite and using the “echo LCD” command as my posts above, I get the bitmap squashed to the top half of the 800x600 LCD:

    The ovals should be circles, and I think the image begins repeating again on the right. Bottom half of the screen is blank.

    I put in some debug code to dump the VENC and OSD registers (hex values):

    --------------------- Video Encoder/Digital LCD (VENC) Registers --------------------

    VMOD     : 2411   VIDCTL   : 2000   VDPRO    : 0000   SYNCCTL  : 000F
    HSPLS    : 0009   VSPLS    : 0009   HINT     : 041F   HSTART   : 0000
    HVALID   : 0320   VINT     : 0274   VSTART   : 0000   VVALID   : 0258
    HSDLY    : 0000   VSDLY    : 0000   YCCTL    : 0000   RGBCTL   : 0000
    RGBCLP   : FF00   LINECTL  : 0000   CULLLINE : 0000   LCDOUT   : 0001
    BRTS     : 0000   BRTW     : 0000   ACCTL    : 0000   PWMP     : 0000
    PWMW     : 0000   DCLKCTL  : 0800   DCLKPTN0 : 0001   DCLKPTN1 : 0000
    DCLKPTN2 : 0000   DCLKPTN3 : 0000   DCLKPTN0A: 0000   DCLKPTN1A: 0000
    DCLKPTN2A: 0000   DCLKPTN3A: 0000   DCLKHS   : 0000   DCLKHSA  : 0000
    DCLKHR   : 0000   DCLKVS   : 0000   DCLKVR   : 0000   CAPCTL   : 0000
    CAPDO    : 0000   CAPDE    : 0000   ATR0     : 0000   ATR1     : 0000
    ATR2     : 0000   RSV0     : 0000   VSTAT    : 0000   RAMADR   : 0000
    RAMPORT  : 0000   DACTST   : 1000   YCOLVL   : 0000   SCPROG   : 017A
    RSV1     : 0000   RSV2     : 0000   RSV3     : 0000   CVBS     : 0000
    RSV4     : 0000   ETMG0    : 0000   ETMG1    : 0000   RSV5     : 0000
    RSV6     : 0000   RSV7     : 0000   RSV8     : 0000   RSV9     : 0000
    RSV10    : 0000   RSV11    : 0000   RSV12    : 0000   RSV13    : 0000
    RSV14    : 0000   DRGBX0   : 0400   DRGBX1   : 057C   DRGBX2   : 0159
    DRGBX3   : 02CB   DRGBX4   : 06EE   VSTARTA  : 0000   OSDCLK0  : 0000
    OSDCLK1  : 0001   HVLDCL0  : 0000   HVLDCL1  : 0000   OSDHADV  : 0000
    CLKCTL   : 0011   GAMCTL   : 0000

    ------------------- OSD Registers ------------------------
    MODE     : 0000   VIDWINMD : 0303   OSDWIN0MD: 303B   OSDWIN1MD: 8002
    RECTCUR  : 0000   Reserved : 0000   VIDWIN0OFST: 002D   VIDWIN1OFST: 002D
    OSDWIN0OFST: 002D   OSDWIN1OFST: 000C   VIDWIN0ADH: 0630   VIDWIN0ADL: 0000
    VIDWIN1ADL: 0000   OSDWINADH: 0403   OSDWIN0ADL: 0000   OSDWIN1ADL: 0000
    BASEPX   : 0000   BASEPY   : 0000   VIDWIN0XP: 0000   VIDWIN0YP: 0000
    VIDWIN0XL: 02D0   VIDWIN0YL: 0240   VIDWIN1XP: 0000   VIDWIN1YP: 0000
    VIDWIN1XL: 02D0   VIDWIN1YL: 0240   OSDWIN0XP: 0000   OSDWIN0YP: 0000
    OSDWIN0XL: 0320   OSDWIN0YL: 0258   OSDWIN1XP: 0000   OSDWIN1YP: 0000
    OSDWIN1XL: 0320   OSDWIN1YL: 0258   CURXP    : 0000   CURYP    : 0000
    CURXL    : 0000   CURYL    : 0000   Reserved : 0000   Reserved : 0000
    W0BMP01  : 0000   W0BMP23  : 0000   W0BMP45  : 0000   W0BMP67  : 0000
    W0BMP89  : 0000   W0BMPAB  : 0000   W0BMPCD  : 0000   W0BMPEF  : 0000
    W1BMP01  : 0000   W1BMP23  : 0000   W1BMP45  : 0000   W1BMP67  : 0000
    W1BMP89  : 0000   W1BMPAB  : 0000   W1BMPCD  : 0000   W1BMPEF  : 0000
    VBINDRY  : 0000   EXTMODE  : 0000   MISCCTL  : 0010   CLUTRAMYCB: 0000
    CLUTRAMCR: 0000   TRANSPVALL: 0000   TRANSPVALU: 0000   TRANSPBMPIDX: 0000

    [I guess can’t set proper values for OSDWIN1OFST  and OSDWIN0OFST as the TI app writing the bitmap expects a display width of 720 and writes into the OSD buffer assuming that width – if I change these values to match an 800 wide display the picture goes screwy. In any case these values probably don’t matter at the moment, it’s the overall height that’s the problem.]

    Does anything look bad with these registers? I think the OSD setting widths and heights look OK, and the frame versus field selections in the registers appear to be OK to set this for non-interlaced full frame. Many thanks. 

  • 0 in reply to SteveG10854
    Intellectual 510 points

    Got full screen - the frame/field bits were set the wrong way. This causes VPBE to skip every other line.

    To get an image, I set the LCD width and height to 720x576 in the OSD registers, but left the timing regs as per an 800x600. This gives an OSD image over most of the screen. Now to get the video displayed on the LCD too.

    Still need to boot into composite then switch to LCD though, so there is still something specific being set up by the composite selection....