tvp5158 4D1 16bit <---> omapl138

SLES243F is old. Please make sure you are using the latest datasheet available from www.ti.com.

The TVP5158 contains 4 decoder cores so you need to ensure that all 4 cores are configured. Register FEh & FFh control which of the cores are read/written by an I2C transaction.

Each core is completely independent hence if the blue screen is enabled/forced for a specific channel then it will simply look like the input video for that channel is blue screen. It is not treated any different to active video, so combining to a super frame is perfectly valid.

Unfortunately I can't comment on theEAV2SAV and support for these decoders is now extremely limited (all but one video device is now not recommended for new designs).

All I can suggest is that you examine the data with a logic analyzer.

Usually this period length is not critical since the data sink should look for the synchronization codes and ignore everything outside SAV/EAV.

BR,

Steve

Hi Steve,

Thanks for listening. I am the other guy who's working on the same setup along with OP - I mean, physically the same processor and decoder PCB :) I've got the latest document from the net, but there seem to be no good clues...

I've made sure the wiring to VPIF (2x8 data lines and 2 clock inputs) is correct, and an SDTV digital BT.656 video is streaming in to CC0 and CC1 of the VPIF. The situation changes in the 4-chan D1 line-interleaved 16 bit mode.

I cannot get any 4-ch diagnostic SF status in the D0-D1 and D2-D3 registers. Does this mean that there is no data out? I wonder if I did not init some important register in the decoder. Yes, I do control the 0xFE register value to properly init each decoder core.

The problem is that I currently don't have a grip on a scope to test VPIF input lines, but I can see OCLK_P clocks on the multiplexed GPIO pins in the register view vindow of the CCS.

The most crucial question is what others registers shall I setup besides B0 and B2 to get the super frame out?

Thanks for any hints. BTW, which device is recommended at the moment?

When you say you don't see any status register updates I assume you mean in the OMAP device? Unfortunately I know absolutely nothing about the OMAP hardware or software so can't help much with that.

Have a look at this posting. It might help...

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/t/146499.aspx

I believe that the TVP setup only requires B0h to be set to A8h for 4 channel D1 ITU1120 at 54MHz or set to A0h for 4 channel D1 ITU656 at 108MHz.

Currently we do not have any other recommended devices.

BR,

Steve

Steve Clynes said:

When you say you don't see any status register updates I assume you mean in the OMAP device? Unfortunately I know absolutely nothing about the OMAP hardware or software so can't help much with that.

No, I meant the status registers in TVP5158 device, 0xD0, 0xD1 and 0xD2, 0xD3:

// Super-frame EAV2SAV duration status LSBs D0h R
// Super-frame EAV2SAV duration status MSBs D1h R
// Super-frame SAV2EAV duration status LSBs D2h R
// Super-frame SAV2EAV duration status MSBs D3h R

Thanks,

Andrew

Hmm, I don't know why these are not updating for you.

Are you using these as a check that you have configured things correctly or do you actually need their values for subsequent processing?

BR,

Steve

So do I... Could it be that I use an older revision of the TVP5158 chip?

I thought of using these registers for both purposes, to check decoder settings/vide out and use correct values in VPIF settings.

Rgds,

Andrew

I doubt there is an issue with older revisions, but it is possible.

You could try downloading the latest patch code from here...

http://software-dl.ti.com/dsps/dsps_public_sw/dsps_swops_houston/ANALOG_VIDEO/Analog_Video_Decoder_Versions.htm

BR,

Steve

Thanks Steve, I'll try that.

BTW, RAM reprogramming - is it a one time procedure, or needs to be done every now and then on power up? Is it a non-volatile RAM in the device?

Rgds,

Andrew

It is RAM so needs to be done after every power up.

BR,

Steve

Time passed... More time passed... Even more time passed... Hello there! :-)

With your help we've got it working so that the original problem with 4 channel video has gone away. Thanks Steve!

For a while we've been analyzed captured video streams. We found out that each channel has a cluster of some 8 or 12 (doesn't matter actually) empty (dark) scanlines, appearing only in the second PAL video field, beginning at an arbitrary AV line number. We've never seen it in the first field. The user's manual says that one can observe empty lines allright.

The question is now if these dark lines might be fought over by e.g. using a modified patch code?

Steve Clynes said:

It is RAM so needs to be done after every power up.

Rgds,

Andrew

Andrew,

The is no way to eliminate the blank lines. These blank lines are inserted in order to compensate for the fact that each analog video stream that is being decoded is completely asynchronous to the other analog video inputs but the digital outputs are synchronous.

You will find that all channels except the primary channel will have blank lines and/or 'missing' blanking lines in order to compensate.

Regarding patch code specific patch code does not fix an issue that affects you then you do not need to download patch code.
 If you need the patch code then you must download it. It is no different to configuring the device. Forgetting to configure the device would give the same incorrect result. Don't forget :-)

BR,

Steve

Thanks Steve, I won't :-) However, to err is humane, just as I did in my previous post: for some reason unknown I misprinted "we've been analyzed" when in fact I was going to print "we've been analyzing" :-)

Actually blank lines are visible even in the primary channel, always in the second field as well. But if this is part of hardware synchronization method then this answers my last question. We should continue to live with the blanks :-)

I am all done for now. Thanks and regards,

Andrew

Andrew,

"to err is human" true, but to REALLY mess things up requires a computer :-)

Glad you are now getting the results you expect.

There should be line and channel information in the line headers to help decode and re-assemble the image downstream.

BR,

Steve

Dear Steve,

I'm Sergej, we are all from one project who left here posts.

The short description of problem is on images I attached. These are 2 images of second fields from 2 frames sampled in different time Please look at them and compare - you will see black horizontal bar which appears on each second field of each frame and it goes from bottom up. Each such black bar contains 8 strings. We cannot find the reason by which these 8 strings disappear on each second field in each frame on all 4x channels. The format is PAL 720x576. Now it is the most seriuos problem we have in our device. Please help to solve it.

Thank you!

Looking forward your answer!

Sergej.

Does anybody know the anwer?

Sorry for the delay in responding but I have been out of the office.

I don't know enough about the OMAP device but I think the issue is there. The OMAP device will receive a continuous stream of data that needs to be processed in order to extract the active video lines and to which channel they belong.

My feeling is that the OMAP device hardware and/or software are assuming certain blanking periods and skipping video data for these lines.

Are you able to capture the TVP digital output with a logic analyzer so that we can look at the data to check where the black lines are being generated?

BR,

Steve

Hello, Steve. Thanks for the long-awaited answer. Checking signals by the analyzer will take time. Now tell us, do you have any driver software for running 4 channel PAL for OMAPL138? We are seeing a problem on all 4 channels and only on the second field. We have already tried a lot, but it does not give the result.
Thanks in advance.

I am not aware of an OMAP L138 driver since, as I mentioned, the capture port was never designed to capture from the TVP5158.

You can try posting the question in the OMAP forums.

BR,

Steve

Let it be any processor for which a driver in mode 4 channel PAL. There is such a driver?

There are drivers for the DM816x and DM814x but these devices have specific hardware to do hardware separation of the video streams so will not help.

BR,

Steve

Nothing new. All digitized stream (Channel 4) written in a superframe, all conceivable BT codes for all rows of all channels are recorded in SC [4], i.e. all video story can be restored without an oscilloscope / analyzer.

Videoport implied in the description of 5158 - a copy of the DM6467's video
in OMAP137/137, and configured correctly.

Dark lines - obviously video line and not horizontal forms. it
follows from SC [] codes for these rows.
Steve, waiting for concrete answers in the case.

Thank you.

I am not sure what I am to answer?

The TVP will not blank out active video lines.

Without verification with a logic analyzer of the data stream content I can't comment any further.

This appears to be a processor side issue.

BR,

Steve

We can not verify the analyzer quickly - it will take time and we never did it and we hav't video anylizer. Dear Steve, we have substantial evidence that the blank lines are just a decoder and processor that has nothing to do with it. When you receive a blank line processor receives a stream of code - 0x01010101 (see document). We accept exactly 568 lines per frame, in which the code is not 0x01010101. The processor can not insert this code. Please respond. We would also like to ask - if it possible to send code of our driver for you for testing purposes?

Unfortunately I have no way to test any code you send.

Dear Steve, please excuse us for persistence, because there is no assumption about the correct operation of the chip and we have to figure out who is to blame. If we show by analizer that the problem in the chip, that's next? You do not have the ability to test code, so how we will solve the problem and who will be responsible for it, in case of not correct work of chip? We need good technical support.

I understand, and will do my best but the TVP5158 is NRND (Not Recommended for New Designs) so design in support is extremely limited.

We have many, many customers using the TVP5158 and I have never encountered this issue before so cannot comment much further about where the issue really resides without looking directly at the data output from the TVP.

What registers are you writing in the TVP? Don't write/read any reserved registers. I believe that the TVP setup only requires B0h to be set to A8h for 4 channel D1 ITU1120 at 54MHz or set to A0h for 4 channel D1 ITU656 at 108MHz and register B2h to enable the required output ports.

BR,

Steve

Hello, Steve. Say, could you give us contacts of professionals who could use this decoder with 4 Channel PAL with the same video ports as that of OMAPL138? Now we are thinking of ways to solve the problems, but in now we would like to discuss with anybody who have experience with the decoder.

Thank you!

Hi, Steve.
Please tell us is it possible that the frame from a camera may be placed (divided by two parts) in two adjacent superframes? Where we can get more detailed description about algorithm packing lines from 4 channels to 16 bits port and about parsing lines from the port?

Thank you.

The frames cannot be packed together, no. The TVP5158 does not have frame buffer memories and only has memories for a few video lines to allow it to align the streams horizontally.

Recall that the source video input signals are not exactly the same frequency and are not phase aligned so they will all shift vertically with respect to all the other inputs over time. If you have an oscilloscope with a video trigger you can easily see this by triggering one channel on one video signal and looking at multiple video sources at the same time on other channels.

The header contains both the channel and the line number and should be used to extract and de-mux each stream.

I will try to find someone who has worked with this on the DaVinci processors since this is really a processor side issue.

You might also try posting on the OMAP forums to see if anyone else has connected the TVP5158 to the L138. I don't support the L138 so can't comment much, sorry.

BR,

Steve