• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 97 subscribers
  • Views 419 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.

ADV7171 Data Issues?

Helmut Forren
Mastermind 6805 points

At http://e2e.ti.com/support/embedded/f/354/p/97614/341121.aspx#341121 I've describe "ADV7171 video output sync issues".

At http://e2e.ti.com/support/embedded/f/354/p/97617/341126.aspx#341126 I've described "ADV7171 fuzzy output issue".

Now I'm wondering if it's all just a DATA issue.

I upgraded my driver in the Linux kernel to alternate between ADV7171-generated color bars and data-to-output, each time I run my application.  When the ADV7171-generatedcolor bars run, I get a great stable display.  The white bar on the left is white.  The black bar on the right is black.  Everything looks like http://aaronstarmer.com/blog/wp-content/uploads/2010/06/EBU_ColorBars-768x576.png.  The scope trace is OK.  (more on this far below)  All this suggests to me that my analog electronics outside of the ADV7171 are fine.

I also upgraded my DM4647T test program to fill the image with color bars, each bar YUV color coming from a table in the program.  When I run the program, which sends data via Linux O/S and V4L2 drivers to the ADV7171, I get a mess.  I changed my table to make a collection of green, gray, and magenta bars, and the output looks great. 

Whenever I change the first bar to white, YUV=(255,128,128), I get vertical & horizontal sync issues (V: horizontal black lines; H:whole image right shifted).  And on the scope looking at one video line, the time where I should have a sync+backporch+colorburst (refhttp://en.wikipedia.org/wiki/Analog_television#Structure_of_a_video_signal), I have TWO such in a row.  It's as if this YUV combination is causing the ADV7171 to sync again, sync again [humorous studder].  NOTE I'm running in "Mode 0 (CCIR-656): Slave Option" right now.

When I change the first bar to YUV=(185,128,128), the sync sync problems go away, but the colors are bogus.  The YUV=(185,128,128) bar should be just a less bright white, but instead it looks like a light magenta (akin to RGB=(255,196,255)).  The other colors are all wrong, too.  The next bar, yellow (or mustard to my eyes, i think it's supposed to correspond to RGB=(196,196,0)) looks like a slightly darker magenta.  The cyan bar is a bluer magenta.  the green bar looks more like dark mustard.  The magenta bar looks the same as the white bar (akin to RGB=(255,196,255)).  The red bar is a red-orange.  The blue bar is bright-light-blue (akin to RGB=128,196,255).  And the black bar is black but full of white noise (reminiscent of an analog oversaturation problem where white has black noise, but this is black with lots of white noise.)  NOTE ALSO the scope trace for this dingy white is not a flat line (with 27MHz noise) Y value, but a has a fully modulated chroma signal.  So it really is being output as a light magenta color.

All of this makes me wonder about my data.  I have a reliable RGB-YUV converter that I developed while doing some codec work last year.  And I have a reliable RGB-YCbCr converter that I developed while working the the DM6467T EVM (evaluation module) and Hi-Def video.  Even if my conversions were off slightly, it wouldn't cause color troubles this bad.  And it certainly wouldn't cause sync problems merely because of color.

Please help me get to the bottom of this!

This background color is similar to my blue bar, but the blue bar is a little more "brilliant"

 

This is RGB=(255,196,255) and it looks similar to what my dingy white bar looks like.  Dingy white is YUV=(185,128,128)

Thanks very much,

Helmut

About the scope trace, my old 20MHz analog scope doesn't show the 27MHz noise at all.  It doesn't even show the 13.5Mhz version of the noise, either.  While my 60MHz digital scope does show the noise, which has a substantial 13.5MHz component, even when I turn on 20MHz bandwidth limit.  So I think a good portion of the noise is just my test environment and my scope, not the actual board signal.  The noise is coming from the board into the scope, perhaps through the 120V wall supply, but not necessarily from the measured signal itself.  The analog scope trace looks just like http://t0.gstatic.com/images?q=tbn:ANd9GcT4-8E4fn8GHdLztYx0H_I65yG0w64n8rvW_9Tg2hpeyCTD-WuM&t=1, including flat Y signal without chroma.

  • 0
    Mastermind 6805 points

    It occurred to me that I may have a physical data clocking issue.  With a scope, I determined that the eight VPIF_OUTn data lines from the DM6467T are changing on the rising edge of VP_CLK02.  This means the data is stable for latching on the falling clock edge.  However, the ADV7171 latches the data on the rising clock edge, the same clock edge as when the data changes.  It's a miracle that the latched data is even close, probably due to setup and delay conditions.

    So I want to reverse the relative clock phase of the data coming out of the DM6467T, so that data changes on the falling edge and is stable for latching on the rising edge, when the ADV7171 expects it.  On page 227 of the DM6467T datasheet I find Figure 7-40 "VPIF Channels 2/3 Video Display Data Output Timing with Respect to VP_CLKO2/3.  It illustrates "Positive Edge Clocking", which is what I see on the scope, as well as "Negative Edge Clocking", which is what I need.  So this tells me the reconfiguration in the DM6467T should be possible.

    However, I can't find in the documentation where to set this, much less in the source code where to handle it.  If you know either or both, please educate me!

    I searched the DM6467T datasheet for the word "edge" and find nowhere anything about this subject.  I search spruer9d.pdf (the VPIF Users Guide) and can't find it either.  I find Table 15 discussing the CLK_EDGE_CTRL_CH2 bit, but this bit is described as "Defines timing relationship between data phase and clock edge for video input data that is connected to VPIF channel 2" [emphasis added].  This says "input", and I'm interested in "output", so it seems CLK_EDGE_CTRL_CH2 is not the correct configuration bit.

    But if I understand spruer9d.pdf Figure 1, channel 2 is ALWAYS an output and never an input.  This means Table 15 language is wrong and it should have read "output".

    Which is it?

    Thanks,

    Helmut

  • 0 in reply to Helmut Forren
    Mastermind 6805 points

    RESOLVED.

    What really got things working well was to set DM6467T CH2_CTRL register CLK_EDGE_CTRL_CH2 bit to 1, in order to have data stable on the correct rising clock edge for the ADV7171 to latch.  It was amazing it worked before at all.  I think the fuzzy's and wrong colors were due to bit errors from latching on the same edge as the data changed, where some bit combinations worked and some didn't, with output or input latency and so forth in the mix.  See http://e2e.ti.com/support/embedded/f/354/p/97626/341641.aspx#341641 for details.

    Evidently the datasheet is WRONG.  The word "input" in the case above should be "output".  A small but perhaps important error.