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.

Is there an ERROR on evm816xiodc_Schematics_RevC pin connections?

Other Parts Discussed in Thread: PCF8575, TVP7002, TVP5147
I was looking at the Rev C schematic and wondered if there was an issue on it. 



On page 25 of the rev C schematic,
It looks like the net for SEL_VIN0_S1 appears to be connected to the net for SEL_VIN1_S1.
What I don't know , based on your schematic capture program and settings, IS SEL_VIN0_S1
actually connected or does it not have scope on this page?  If it does then the setting on
SEL_VIN0_S1 on the digital port U60 will need to follow SEL_VIN1_S1
OR perhaps the off page connector of SEL_VIN1_S1 going into pin 2 of SN74LVC1G04DCK
is not actually in scope meaning that the control of U33 is actually under control of SEL_VIN0_S0

If these pins are not selected properly then I imagine the HDMI input won't work. 

P.S. I guess this isn't a question for the community but something I should ask 
Spectrum Digital directly.  
  • Hello,

    I would first compare these Rev C schematics with the more recent version schematics: http://support.spectrumdigital.com/boards/evm816x/revg/

    If there is still a question, then please contact Spectrum Digital directly.

    Regards,
    Marc

  • Hi,

    I am not sure what are you trying to do here. But if you are trying to setup PCF8575 for reception of input from DVI decoder instead of TVP7002 then you need to do following changes. You need to modify following function under arch/arm/mach-omap2/board-ti8168evm.c. Currently we are setting it for TVP7002 decoder. You just need to set it for DVI decoder. You need to set 1 on that VPS_VC_IO_EXP_SEL_VIN0_S1_MASK bits to select DVI instead of TVP7002.

    "int vps_ti816x_select_video_decoder(int vid_decoder_id)"

    Regards,

    Hardik Shah

  • Thanks Marc,

    The REV C drawing is the "latest" as far as I can tell from their website for the expansion board. This is the board in question. I did ask Spectrum Digital directly. I wan't thinking clearly  when I found it, but if it is true then it could be a warning to the community that you probably get an indeterminate output if SEL_VIN1_S1 is set to 0 and SEL_VIN0_S1 is set to 1. This could be bad for the chip too if it doesn't handle two conflicting outputs correctly.

    I am waiting for Spectrum Digital to answer for now.

    Tony

  • Thank you Hardik Shah for you answer that is the kind of information I am looking for ultimately.

    My issue is that it "looks like" the VIN0_S1 and VIN1_S1 output bits from the PCF8575 are connected together. I am examining the data sheet to see if you drive them different directions is a problem. The worst that it could mean is that you can't independently control VIN0 and VIN1 . 
    Of course, the schematic could just be out of date OR this was fixed up by the layout designer which means this is a non issue.

    Tony

     

  • Hi,

    I am not seeing both of them tied together in schematics. Do you have net for it and there you are seeing it tied.

    Regards,

    Hardik Shah

  • Sure, no problem.

    If you look at sheet 25 of 35 in the upper left corner. You will see SEL_VIN1_S1 , it enters pin 2 of
    U34. That same wire is connected to S1 ,Pin 56 of U33 on that page.

    You will see that wire is labeled SEL_VIN0_S1 (note the 0). Now , depending on the cad package,
    IF you label the wire it COULD be the same net used on another page.

    That is the question really, did spectrum digital connect these two nets together? If they did then there
    is a problem, if not then I am just making a bunch of noise and I apologize.

     I have this question in to them now and I am waiting for their reply. 
     

    If it is an issue then you just have to set SEL_VIN1_S1 to an input and use SEL_VIN0_S1 to
    control the input selection for VIN1 and VIN0.  

    P.S. I did get a reply, but it isn't resolved in my opinion yet. They gave me a new link
    (which was the one I had used all along but was willing to give the benefit of the doubt)
    but the Expansion I/O still has an incorrect label. AGAIN , non of this is proven until someone
    verifies the netlist.  I suppose, I could just disassemble my  set of boards, which I am
    always afraid to do,  and try to see if the two pins show up as a short on a meter. 

  • NOT A PROBLEM!!!! 

    It seems that this isn't an issue, I used a meter to check for direct short between the pins and none appears to exist. So the label didn't make it into the final board it appears. This is good because that could have caused strange operational errors.

    My apologies to all for bringing up something that looked more serious than it actually was.

    Tony

  • In case you are still monitoring this question, I have an aside. 
    You mentioned how to set this in code for the DVI encoder but I was under the impression that this channel wasn't supported in code yet. 
    Is this a true statement? I mean I can connect up to the DVI but without some driver support it isn't usable, or am I confused on all the other posts on this input?

     Can I simply set this bit in the structure in ti81x_fb.c , recompile and use say capture_encode example and its input will be from DVI??

    Tony

     

  • Hi,

    You are correct DVI is not supported as of now. I thought you are planing to develop that driver so I thought of giving directions.

    Regards,

    Hardik Shah

  • That would be the plan but as you hear too often on this message board, I am in a time crunch. Also I haven't been able to get detailed specification from Silicon Image, which I imagine may be necessary to complete the task, unless the default power up for the chip is something usable.

    Thanks 

  • Hi Hardik,

    One question, is it possible to use both TVPs at the same time using the DM816x-EVM? 

    Thanks in advance

  • Hi,

    There is TVP5147 and TVP7002 on io expansion board. You can use Two TVPs together one on each VIP port. Like TVP7002 one  each on both ports of TVP5147 on one and TVP7002 on other.

  • Hi Hardik,

    Thanks for your quick response.

    I am trying to get the dual capture from component working on the DM816x-EVM basically following your instructions on this post:
    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/160009/625289.aspx#625289

    of course without comment the subdevice calls 

    I already set the correct pin muxes and also I modified the driver to register both TVP7002 (changed for (i = 0; i < 2; i++)), this is ok, however when I try to run the saLoopBack demo using /dev/video5 it fails, it doesn't recognise the video format from input  and it works just if I connect the video source to the component input connected to VIP0 even if use video5 instead of video0 it keeps trying to get the format and frames from VIP0.

    I'm using the ezsdk 5.05.01.04 capturing 1080p, and I think that in order to get the dual capture working I need to get the saLoopback working with the VIP1 as first step.

    Hardik do you have some comment about what could be wrong with this approach? am I missing something?

    why it is trying to use the VIP0 instead of VIP1 if I am using /dev/video5?

    Your comments are really appreciated!

  • Hi All,

    I got this working with the DM8168 EVM. You can find a patch with the changes that I did in the following link:

    https://www.ridgerun.com/developer/wiki/index.php/Getting_Started_Guide_for_DM8168_EVM#Dual_Capture_Support

    Regards,

    -David

  • Hi,

    This is great. hats off to you for getting it working. One small request please attach the patch as well on to that link with your signoff so that someone can download and apply it cleanly.

  • Hi Hardik,

      After get the dual capture working and test it with the saLoopBack application I started with gstreamer, mainly I wanted to run two different pipelines, each pipeline capturing from a different port.

    However, I found that gstreamer is having problems to work properly in this case, basically you won't be able to capture frames using v4l2src plugin if the SoG signal (also called SYNC_DET or TIM4_OUT/GPIO on sheet 25 in the schematics http://support.spectrumdigital.com/boards/evm816xiodc/revc/files/evm816xiodc_Schematics_RevC.pdf) is disabled.

    As you can see in the schematics the chip labeled as U66 (Dual multiplexer) would handle this signal, however, if this chip is enabled and you want to use both TVP7002 at the same time the SoG of both TVPs would end in the same wire which would be a problem, so I decided to disable this chip since I am capturing from component YPbPr where the sync signals are embedded (SoG wouldn't be needed). It seems that this is a problem for gstreamer cause if the SoG is not present v4l2src won't work properly and won't capture frames.

    I tested the following:

    1) I used the saLoopBack application and it always work on both ports, even if the SoG (U66) is disabled.

    2) Running the following pipeline gstreamer won't work:

    gst-launch v4l2src device=/dev/video0 always-copy=false queue-size=12  ! 'video/x-raw-yuv-strided,format=(fourcc)NV12,width=1920,height=1080,framerate=(fraction)60/1' !  omxbufferalloc numBuffers=12 ! omx_scaler ! gstperf  ! v4l2sink sync=false  -v

    I get the error:

    "ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed trying to get video frames from device '/dev/video0'.

    Additional debug info:
    ../../../src/sys/v4l2/gstv4l2bufferpool.c(670): gst_v4l2_buffer_pool_dqbuf (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
    The buffer type is not supported, or the index is out of bounds, or no buffers have been allocated yet, or the userptr or length are invalid. device /dev/video0"

    3) Once the pipeline has been run, I am not able to use the saLoopBack application anymore, a reboot is needed.


    On the U66 chip :


    if I enable the SoG signal just for the TVP2 and disable the SoG for the TVP1 I am able to capture from the second port properly:

    gst-launch v4l2src device=/dev/video5 always-copy=false queue-size=12  ! 'video/x-raw-yuv-strided,format=(fourcc)NV12,width=1920,height=1080,framerate=(fraction)60/1' !  omxbufferalloc numBuffers=12 ! omx_scaler ! gstperf  ! v4l2sink sync=false  -v 

    if I enable the SoG signal just for the TVP1 and disable the SoG for the TVP2 I am able to capture from the first port properly:

    gst-launch v4l2src device=/dev/video0 always-copy=false queue-size=12  ! 'video/x-raw-yuv-strided,format=(fourcc)NV12,width=1920,height=1080,framerate=(fraction)60/1' !  omxbufferalloc numBuffers=12 ! omx_scaler ! gstperf  ! v4l2sink sync=false  -v 

    If I disable the chip I can't capture from any port. However the saLoopBack application works,

    Do you know if there is some limitation on gstreamer about this? why does gstreamer always need the SoG even if the sync signals are embedded?

    I have checked the TVP registers before and after run the gstreamer pipelines and they are properly configured so the problem is not in the TVP side.

    Any help on this is really appreciated!

    -David