TVP5147 unreliable vertical sync

Helmut,

Do you have a way to reset or restart the DM6467 frame capture after you see the vertical offset, to see if the correct position is restored?

You are observing the vertical offset while the DVD is playing in standard play?

Larry,

Regarding your first sentence:

I not sure I understand.  I can stop and restart the application, and the vertical offset is different every time.  I haven't tried modifying the application itself to be able to stop and start the capture.  Please be more specific about what you mean "restart the DM6467 frame capture".  For example, tell me a software function name involved in this.  Do you mean Capture_create()?

Also, I was thinking the TVP5147 was not properly locking onto the image vertical position.  But it sounds like you're implying that the TVP5147 may be locking fine, but the DM6467 VPIF input is not locking onto the TVP5147 data stream properly.  Please confirm if this is your suspicion.  I hadn't thought of that, and can learn more and track stuff down in that area.

It appears that the TVP5147 has HS/CS/GPIO and VS/VBLK/GPIO pins.  Perhaps it's already outputing HS and VS.  I could scope that against the NTSC input, and see if the positioning is reliable and correct.  This would binary divide [and conquer] the problem, determining if it's in the TVP5147 or DM6467.  Do you concur?

Regarding your second sentence:

Note that I am splitting my NTSC input between my prototype and a monitor.  The monitor ALWAYS looks correct, vertically, so I'm fairly sure the NTSC signal is well formed.  

Nevertheless, when you say "standard play", I think you mean to put in a commercially produced DVD (rather than one I burned) and actually play the darned thing (rather than freezing my still image slide show).  Interesting!?!  I have noticed bits in the TVP5147 registers having to do with cameras vs vcr's.  Is there a difference?  Please be aware that I'm testing with still images from a DVD player, but my end product will take input from a camera.  Do I need to be concerned about the difference?

I'll keep the check you suggest in mind...

Thanks,

Helmut

Helmut,

The first sentence was related to the TVP being properly locked, but the frame buffer being out of sync, or somehow out of position.    It sounds like restarting capture could actually be causing the shift.   I am not that familiar with the software, so I do not have a function call to recommned.  We may need to work that through another forum for this.

Checking VSOUT and also the TVP vertical lock status in the TVP I2C REG 3A would be a good idea.  The TVP VSOUT should be properly aligned to video when the TVP is locked to NTSC.   There could still be some TVP/frame buffer startup issue, even if the TVP shows a locked stated after the input MUX is switched to the active input channel.

"Standard play" refers to normal play vs. "Pause".  I thought you mentioned that a problem occurerd during "Pause".

Larry,

I find that the VS output of the TVP5147 is indeed active and very consistent with the NTSC input waveform, even while I'm experiencing a vertical frame shift as large as a third of a frame.  This strongly suggests that the problem is in the DVM6467 and/or its input from the TVP5147, rather than in the TVP5147 and/or its NTSC input. (My Internet was down earlier this morning.  I wrote a draft of this post.  Only just now do I see your TVP I2C REG 3A suggestion.  I'll keep that in my back pocket.)

I don't see how this is possible.  The DM6467's VPIF input should be locking onto embedded syncs in the digital data from the TVP5147. One guess I have is that the embedded vertical sync info is MISSING, and the VPIF is doing the best that it can, which sometimes misses. (I just researched BT.656 and see the vertical sync is embedded in the EAV/SAV codes.  I don't see how the vertical sync info can be missing while the horizontal sync is always looking good.)

Be aware that I have two NTSC inputs (two TVP5147's) using DaVinci channels 0 and 1, plus one VGA output (one THS8200) using DaVinci channels 2 and 3.  This gives me both a diagnostic advantage as well as a possibility for a cause of the problem, but only a "possibility".

Diagnostics wise, I can tell one NTSC input is shifted relative to another.  This assures me that the problem is with receiving the NTSC input, and not with my application code or VGA output generation.

One possible problem is that I had to modify some DMAI/V4L2/VPIF (and perhaps TVP5147) code to get the second NTSC input working.  The existing code supports composite on the first TVP5147, but only s-video on the second.  I had to make it support composite on the second, including the ability to select at all between two inputs of the same format.  I was careful, but I wouldn't think I messed up anything with VPIF timing.

Another possible problem is the fact that my two NTSC inputs are NOT synchronized to each other.  There's a slow shift cycling between them. This is easily seen by scoping both the VS outputs of the two TVP5147's.  You can see the pulses very slowly move relative to one another. Now, this vertical shift problem is random.  The extreme shift problem is somewhat rare.  I have to restart the application many times to get it to happen.  Just now, when I finally got it to happen again, there was a large time shift between the two inputs.  So this makes me wonder if the probability of the failure increases when the two inputs are further away from each other in relative time sync.  I can't be certain of this at all, but it would suggest some interplay between ch0 and ch1.  They do use the exact same crystal clock.  The first TVP5147 has a crystal while the second takes the firsts crystal input.  They each, however, output their own VPIF_CLKIN0 and VPIF_CLKIN1, respectively, that go to the DaVinci and *SHOULD* be being used independently by the VPIF.  (I have not confirmed this, but I haven't forced otherwise either.)

Third, while the application is off, the TVP5147 VS outputs are quiet, so I believe the chips are [turned off] and thus must regain lock when  the application starts again, which they seem to do reliably.  But what about the vpif?  Is it possible that it's not necessarily trying to re-locate the vertical sync info that I believe is embedded in the data from the TVP5147?  Be aware that my prior prototype, that had only one NTSC input (ch0) and one NTSC output (ch2), had some code I added to board-dm646x-evm.c that claims to synchronize the clock sources.  I had to remove that when doing two NTSC input and one VGA output.  I didn't analyze why.  It's been half a year, so my memory is foggy on why I put that in.  Looking at code comments, it was setting the ch2 and ch3 clock (I think I only used ch2, not ch3) to be routed from the ch0 clock.  This involved variables VIDCLKCTL, VCH2CLK_VP_CLKIN0 and VCH3CLK_VP_CLKIN0.  I do not believe this is germane to the problem, but I could be mistaken.  I believe this is strictly a capture problem, so the setting of output clocks should not matter.  The fact that the two NTSC inputs obviate that one is vertically shifted is the key, regardless of what happens on the way out.  

(((Regarding play vs pause, I am paused.  I really need to work in paused mode, so I guess I'm not going to entertain this being the cause.  The TVP5147's seem to be locking on fine, so how could the play-vs-pause of the DVD players be feeding something weird through the TVP5147 and on to the DM6467?)))

Any comments or suggestions?

Thanks VERY much,

Helmut

FYI, regarding VS output from TVP5147, see http://www.ti.com/lit/ds/symlink/tvp5147m1.pdf page 26 Figure 2-12, top half.  My NTSC scope trace looks alot like the first line, with 3 frames (6 fields) of mostly low trace easily visible (numbered 4,5,6 in the figure).  My VS output looks like the VS trace on the graph, but always consistently shifted right a bit.  I don't know if this VS trace means the actual VS pin.  The VS pin goes low part way through the 4th of 6 fields, while the figure shows it doing so part way through the 1st of 6 fields.  This NEVER changes, though, so I think it's correct.  The difference could be some register programming (FID?) that I've inherited from DMAI/V4L2/VPIF/TVP5147 software in the DVSDK or GIT.

Thanks, Larry.  I intend to spend the first half of today on this.  Hopefully I'll solve it in just half a day...

FYI, I just solved this same issued on my OMAP-L138 VPIF / TVP5147 system by waiting to bring the VPIF out of reset until the TVP5147 reports acquiring lock.

-Brad

RESOLVED.  Thanks for your help, Larry.