• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 101 subscribers
  • Views 836 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.

DM648 Video Port Reset Failure

vcar4195
Intellectual 285 points

I used the psp drive for my development. I opened the project at "pspdrivers\system\dm648\bios\evmDM648\video\sample\build\raw_capture_loopback" and build it, when I download the *.out file to my customized board, the DSP hangs at the following line in vportcap.c:

              while (port->vportBase->VP_CTL & CSL_VPORT_VP_CTL_VPRST_MASK); 

It seems that the video port could not be reset successfully. While I searched in google and I found some people also met this problem, however there were not solutions.

 

On my customized board all five video ports are connected to FPGA directly, and the FPGA also provided 30MHz clock on the video capture port CLK0 pin, other pins are all gound at beginning. So what would the cause be which make the capture port reset failure?

 

I also test some other sample projects using capture port or display port or both. None of these video ports could be successfully reset, and the DSP hangs at mdBindDev() function forever. Is this a software issue or hardware issue?

  • 0
    Expert 1575 points

    Hi,

    I had the same problem. I thought that reason is that VP needs a clock input to complete the reset (see datasheet spruem1, VPCTL, VPRST):

    Flush all FIFOs and set all port registers to their initial values. VCLK1 and VCLK2 are
    configured as inputs and all VDATA and VCTL pins are placed in high impedance.
    Auto-cleared after reset is complete.
    The VPRST bit *** may take several clock cycles *** to clear to 0. The VPRST bit should be
    polled to make sure the bit is cleared prior to writing to the video port registers.

     

     

    In my case I have to connect a camera to make the reset finish. I have cameras connected on the EVM648 daughter card (VP2). First I switch the MSP430 mux so that the DC pins are connected to VP2. When I have no camera connected, Videoport reset hangs as described in your posting.

    Maybe VP not just requires a clock but also an edge on the CSync-Pin (VP_CTL0/1) in order to complete the reset? Are you sure that your FPGA clocks reach the right VP inputs?

    If you find out the solution please post it here, it would be interesting for me.

    best regards,

    Thomas

  • 0 in reply to Thomas9070
    Intellectual 355 points

    Thomas said:

    Hi,

    I had the same problem. I thought that reason is that VP needs a clock input to complete the reset (see datasheet spruem1, VPCTL, VPRST):

    Flush all FIFOs and set all port registers to their initial values. VCLK1 and VCLK2 are
    configured as inputs and all VDATA and VCTL pins are placed in high impedance.
    Auto-cleared after reset is complete.
    The VPRST bit *** may take several clock cycles *** to clear to 0. The VPRST bit should be
    polled to make sure the bit is cleared prior to writing to the video port registers.

     

     

    In my case I have to connect a camera to make the reset finish. I have cameras connected on the EVM648 daughter card (VP2). First I switch the MSP430 mux so that the DC pins are connected to VP2. When I have no camera connected, Videoport reset hangs as described in your posting.

    Maybe VP not just requires a clock but also an edge on the CSync-Pin (VP_CTL0/1) in order to complete the reset? Are you sure that your FPGA clocks reach the right VP inputs?

    If you find out the solution please post it here, it would be interesting for me.

    best regards,

    Thomas

    I am sure that the FPGA provide 30MHz clock both at VP VCLK0 and VCLK1.

    The problem is that if I configure the video port to display mode, DSP still hangs at waiting VPRST bit reset. In display mode, all the VP pins are output pins, and even I do not provide the clock, the DSP has no reasons to hang!

    And I am wondering how could this kind of reset could be failed. What a strange issue!

  • 0 in reply to vcar9962
    Intellectual 720 points

    Thanks for bringing this issue up.  I, too, have been seeing this problem where I'm trying to get the VICPORT to reset, only to see it never come out of reset.  I've checked all of the VIC clocks and they have been running.

     

  • 0 in reply to JRasmussen
    Expert 1575 points

    Hi James,

    do you know the reason for the problem in your case?

    I tested it again right now on my EVM648 board: When I connect a camera on DC the reset finishes, when it is disconnected it does not.

    • First I switch the EVM648 MSP430 MUX to "Videoport 2 connected to DC".
    • Without any camera the VP_CLK0 is 3V3 on my board - with the camera it is clocking.
    • VC_CTL0 is 3V3 without camera - with camera its a 'standard' combined V/HSYNC signal
    • The data pins (D2..D9) are low (0V) without camera, with camera they are toggling (depending on the data from the camera)

    so the only thing that changes is the clock and that there are edges on the VC_CTL pin - I guess that VP requires these edges to finish the reset.

    best regards,

    Thomas

  • 0 in reply to Thomas9070
    TI__Intellectual 2130 points

    Hi,

    I am posting on behalf of my colleague Sivaraj

    If you are working on the DM648 EVM, then before running any of the VPORT sample application, the muxes in the EVM should be properly set.

    This can be done by using the EVM GEL file. The steps to run a sample application are provided in section 7.2 of the VPORT driver user guide present in “pspdrivers_1_10_01\packages\ti\sdo\pspdrivers\drivers\vport\docs”.

     If you are using a custom board, make sure the clock (VCLKIN) to the VPORT is ticking before initializing the VPORT using the driver.

    This holds well even if the VPORT is configured in display mode.

    Because the VCLK0 (VCLKIN) pin of the VPORT is always an input pin!!

    thanks

    regards

    sathya

  • 0 in reply to sathya2149
    Intellectual 285 points

    sathya said:

    Hi,

    I am posting on behalf of my colleague Sivaraj

    If you are working on the DM648 EVM, then before running any of the VPORT sample application, the muxes in the EVM should be properly set.
    This can be done by using the EVM GEL file. The steps to run a sample application are provided in section 7.2 of the VPORT driver user guide present in “pspdrivers_1_10_01\packages\ti\sdo\pspdrivers\drivers\vport\docs”.
     If you are using a custom board, make sure the clock (VCLKIN) to the VPORT is ticking before initializing the VPORT using the driver.
    This holds well even if the VPORT is configured in display mode.
    Because the VCLK0 (VCLKIN) pin of the VPORT is always an input pin!!
    thanks
    regards
    sathya

    I solved my problem finally according to your post.

    Thank you!

  • 0 in reply to sathya2149
    Expert 1575 points

    Hi Sathya,

    so if I understand you correctly, (if the EVM-MUXes are correct) the VCLKIN is the only requirement for the Videoport to finish the reset? Is it true that for example edges on VC_CTL0 are not required? This was my guess since James posted some days back that he was sure to have VCLKIN and still the Reset was not finished.

    regards,

    Thomas

  • 0 in reply to Thomas9070
    TI__Intellectual 2130 points

    Posting on behalf of sivaraj once again

     

    Toggling of CLKIN pin alone is sufficient to bring the VPORT out of reset

     

    regards

    sathya


  • 0 in reply to Thomas9070
    Intellectual 285 points

    Thomas said:

    Hi Sathya,

    so if I understand you correctly, (if the EVM-MUXes are correct) the VCLKIN is the only requirement for the Videoport to finish the reset? Is it true that for example edges on VC_CTL0 are not required? This was my guess since James posted some days back that he was sure to have VCLKIN and still the Reset was not finished.

    regards,

    Thomas

     

     

    On my custom board, both VCLKIN and VC_CTL0 are required to be toggling to bring capture port out of reset. You can have a try. For display port, only VCLKIN ia enough.

  • 0 in reply to vcar4195
    Intellectual 720 points

    vcar said:

    Hi Sathya,

    so if I understand you correctly, (if the EVM-MUXes are correct) the VCLKIN is the only requirement for the Videoport to finish the reset? Is it true that for example edges on VC_CTL0 are not required? This was my guess since James posted some days back that he was sure to have VCLKIN and still the Reset was not finished.

    regards,

    Thomas

     

     

    On my custom board, both VCLKIN and VC_CTL0 are required to be toggling to bring capture port out of reset. You can have a try. For display port, only VCLKIN ia enough.

    [/quote]

    Hi Sathya and Thomas,

    Sorry I hadn't gotten back with you until now, but I have been investigating the VCLKIN situation on our board, and it is very possible that we don't have the VCLKIN clock at all times.  In our situation, we could be changing the resolution and framesync of our Video Signal, and it is possible that we are changing parameters before the new Video Signal is applied, so when I am wanting to reset the Video Port before putting in the new parameters, it is very possible that there is no VCLKIN signal being applied at the time, which is probably causing my lockup on the Video Port.

    I have asked our Hardware engineer to fix the circuitry to supply a dummy VCLKIN signal (about 27Mhz) when there is no signal applied, then when the circuitry detects the Video Signal, switch the VCLKIN signal to the normal frequency at that time.  I'll let you know if it works.

    Thanks,

    --James

     

  • 0 in reply to JRasmussen
    Intellectual 720 points

    Hi Sathya and Thomas,

    Just a Followup to my last post, of which I'm sorry I took so long...

    Our Hardware Engineer did indeed modify our boards to supply a VCLKIN signal to the Video Port  when there is no video source present.  The Video Port now resets with no problem, so this verifies what you were saying about VCLKIN.

     

    Thanks for the help.