• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 29 subscribers
  • Views 455 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.

DLPC2607: Distorted image

Danilo A.
Mastermind 28700 points
Part Number: DLPC2607

Hi Team,

Can you please help us with our customer's inquiry below?

I'm currently working on an application centered around driving a DLPC2607 through a parallel RGB565 interface. In current tests the image is visibly distorted in a way that has me suspect that I am violating one of the timing constraints on the interface. The image I am trying to project is:

but the image appearing on the projector is:

 The above image was written to the DLPC2607 with a pixel clock speed of 6.25MHz.

I know that the issue might also be with the file I'm trying to write or the utility I'm using to write it so I'm reaching out to those vendors as well. But the situation does improve/worsen if I halve/double the pixel clock. The image below was written to the DLPC2607 with a pixel clock speed of 3.125MHz:

So there does appear to be some correlation between speed and distortion that has me think this issue may be timing related.

I have attached a logic capture of the PCLK, HSYNC, VSYNC, DATEN and D[0-3] signals. The capture was taken with a Saleae logic analyzer and requires Saleae Logic 2 to open.

parallel_RGB_capture.zip

The timing requirements are laid out in the DLPC2607 datasheet in section 6.8

I do believe I am meeting these specs and here's why:

tp_vsw and tp_vpb:

VSYNC is asserted for 2 full lines before valid data is clocked out.

tp_hsw and tp_hpb:

HSYNC is asserted for 5 rising edges before DATAEN is asserted and data is written out

tp_hfp:

There are 9 PCLK cycles between the falling edge of DATAEN and the rising edge of HSYNC.

Furthermore, there are 640 rising PCLK edges per DATAEN i.e. 640 pixels per line being written:

If you're aware of any timing related issue that could cause this behavior I'd be grateful to hear about it.

Regards,

Danilo

  • 0
    TI__Expert 3825 points

    Hi Danilo,

    Oure team member is looing into this request.

    We will get back to you by end of this week.

    Regards,

    Akhil

  • 0 in reply to Akhil Guntumadugu
    TI__Mastermind 28700 points

    Hi Akhil,

    Thank you for your response.Our customer also added,

    I had some questions that I think might help get to the bottom of this:
    1. Should the VSYNC pulse come before or after the data transfer for an image?
    2. I presently use a vertical back porch of 2 lines and a vertical front porch of 1 line. The front porch at the moment is the last line of the prior image being written. No empty line is inserted. How does that work with the vertical sync delay? According to the datasheet this setting needs to be set to be set such that "6 – VFP (min 0) ≤ VSLD ≤ VBP-2", which in my case would be 6-2 ≤ VSLD ≤ 1-2 = 4 ≤ VSLD ≤ -1. Is the minimum setting for VBP actually 6?

    Regards,

    Danilo

  • 0 in reply to Danilo A.
    TI__Mastermind 28700 points

    Hi Akhil,

    I've made some progress on this issue. The distortion seems to be 2 pixels per line. That is, each new line seems to be two pixels short, hence the aggressive left shift.
    I found one of those pixels. Turns out I was writing the first pixel on the same clock cycle that I was asserting DATAEN. That's been fixed and it's improved the distortion and tearing. However, there is still a 1 pixel per line shift at the moment. I've attached an image of the current projection and a new wave capture.

    Will keep looking into things on my end as well, but any help would be greatly appreciated!

    parallel_RGB_capture_2.zip

    Regards,

    Danilo

  • 0 in reply to Danilo A.
    TI__Genius 12785 points

    Hi Danilo,

    It looks like you are making good progress. We'll see what we can do to contribute.

    Would you mind sending all of the video timing information available to you? What is being used to send this video data?

    To address your questions:

    Danilo A. said:
    1. Should the VSYNC pulse come before or after the data transfer for an image?

    The VSYNC will occur at the beginning of the frame. The below image was taken from Section 6.15 of the DLPC2607 datasheet:

    Danilo A. said:
    2. I presently use a vertical back porch of 2 lines and a vertical front porch of 1 line. The front porch at the moment is the last line of the prior image being written. No empty line is inserted. How does that work with the vertical sync delay? According to the datasheet this setting needs to be set to be set such that "6 – VFP (min 0) ≤ VSLD ≤ VBP-2", which in my case would be 6-2 ≤ VSLD ≤ 1-2 = 4 ≤ VSLD ≤ -1. Is the minimum setting for VBP actually 6?

    I will have to get a second opinion on this, but it would I do agree with your logic here. I believe the minimum and maximum are to allow for room to adjust where the minimums listed would be a worst case scenario that will not work when used simultaneously. In the meantime, please try tuning these values such that the 6 – Vertical front porch (tp_vfp)’ (min 0) ≤ Vertical sync line delay ≤ Vertical back porch (tp_vbp) – 2 (max 15) criteria is being met, and let me know if this corrects your issue.

    Regards,

    Austin 

  • 0 in reply to Austin Snyder
    TI__Mastermind 28700 points

    Hi Austin,

    The customer solved the issue. Please see the details of the steps he did.

    The video data is being sent by an Infineon FX3. The last data capture I attached (parallel_RGB_capture_2) is the most recent and comprehensive timing information I have. You can open the data capture with Saleae's Logic software (www.saleae.com/.../).

    I realize that the pattern I'm sending in that capture isn't particularly helpful. I will generate two more for you on Monday with some patterns that will better showcase the lines being written out.

    I will also take some more screenshots.

    He sent another email below.

    As promised, I've generated two captures that I think will help us get to the bottom of this quicker. They're included in the file: New_data_captures.zip. RGB_capture_firstlastpixel is a black image, except for a blue 1 pixel wide bar on both ends. The idea was that this way I could see the first and last pixel of each line on the data bus and verify that I was clocking out 640 pixels of data per line. It does look like that is the case.

    New_data_captures.zip

    The other capture is from writing an image with alternating black and white pixels. Similar idea. However, I found that the Saleae sees a lot of glitches on the control lines (VSYNC, HSYNC, DATAEN). I don't think these glitches are real.

    I have not yet tried adding lines to the vertical back porch. The environment I am in makes adding more lines particularly painful so I wanted to at least check the other timing characteristics first.

    I suspect this may have something to do with the vertical sync line delay or total horizontal blanking.

    I solved the problem! I'm not sure which it ended up being ultimately but I have
    A. delayed the deassertion of DATAEN by one clock cycle and
    B. also increased the vertical front porch from 2 to 20.

    The image now renders properly. (see 20230417_110731.jpg) :-)


    Probably ended up being related to meeting the total vertical blanking timing requirement and vertical line sync spec.

    Thank you very much for your help!

    Regards,

    Danilo