• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 100 subscribers
  • Views 817 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 EVM video driver lockup

chris2476
Intellectual 310 points
Other Parts Discussed in Thread: TVP5154

Hi

When I run my application on the DM648 EVM, sometimes the video driver gets stuck in an FVID_exchange call.  I find this is triggered by a certain video clip where the lights in a room are turned on, washing out the image in white for a few seconds.  It only happens sometimes, and the minute-and-a-half clip will sometimes loop for up to an hour or so before the failure.  I have also been able to trigger this with a live camera and a desk lamp pointed at it, though that is not as reliable.

My driver error interrupt handler indicates that when the driver gets stuck there have been capture fifo over-runs (COVR) on the two frames just before the FVID_Exchange that gets stuck.  The code is stuck in assembly in a EDMA or ACPY function, though I can't remember exactly which.  I tried the FVID_control() call with the VPORT_CMD_COVR_RECOVER command, but that does not help.  (Should I call that from the ISR?  I am not currently calling it there.)

I am trying to reproduce the probem with the DM648 minidemo, but I have not seen it yet.  I think one difference may be that my application uses the video port to down sample interlaced data from 720x480 to 360x480.  Then I just use the first 360x240 field for my application.

I will try changing the demo to also do downsampling to see if I can recreate it there.

Any thoughts?

  • 0
    Intellectual 310 points

    Chris35513 said:

    I think one difference may be that my application uses the video port to down sample interlaced data from 720x480 to 360x480.  Then I just use the first 360x240 field for my application.

    I stand corrected.  I am capturing separate fields, but no downsampling is happening.

     

  • 0
    TI__Mastermind 41665 points

    It sounds like your video decoder is losing sync on the signal, at least temporarily, this could cause the sort of overruns you describe, much like disconnecting and reconnecting the camera could. I have not done too much with the DM648, but in prior similar processors the most common reason for getting stuck in FVID_exchange was due to the video port no longer receiving syncs or a clock, so as a debugging step you may want to check the state of your video decoder to make sure it is still in a proper state and providing syncs/clocks to the DM648.

  • 0 in reply to Bernie Thompson TI
    TI__Expert 4935 points

    Chris,

    Do you use TVP5154 decoder present in the DM648 EVM or use some other decoder to capture video from the camera?

    As quoted by Bernie Thompson, it could be possible that the decoder is not generating any clock or sync signals to the VPORT.  

    What version of PSP drivers or DVSDK are you using?

    Regards,

    Sivaraj R

  • 0 in reply to Sivaraj R3681
    Intellectual 310 points

    I am using the TVP5154 decoder (VP0, Channel A, External Decoder 0). 

    DVSDK version is 1.10.00.26.

    PSP driver version is 1.10.00.09.

  • 0 in reply to chris2476
    TI__Expert 4935 points

    This version of PSP will handle overflow/underrun errors gracefully WITHOUT the intervention of the application.

    Though the application can register notification callbacks when these errors occur.

    To do so, the application has to use VPORT_CMD_SET_VINTCB IOCTL to register the callback. In case of underrun/overrun error, the application has to set vIntMask member of VPORT_VIntCbParams to VPORT_INT_COVR/VPORT_INT_DUND and call this IOCTL. The driver will call the application callback (vIntCbFxn of VPORT_VIntCbParams) when errors occur (after recovering from the error!!). This is just a notification and application don't have to call any recover IOCTLS.

    You can probably use this IOCTL for further debugging.

     

    When such hang happens can you do the following and let me know what you observe?

    1. Probe the TVP5154 clock, HS and VS signals and make sure that they are toggling at proper rates.

    CLK - 27 MHz (Pin number 103)

    HS - 15.75 KHz for NTSC (Pin number 100)

    VS - 60 Hz for NTSC (Pin number 95)

    2. Value of VCA_STAT register for VPORT 0 - keep refreshing this register and check that values are getting updated for every refresh.

    These observation will help us to figure out whether the problem is with TVP5154-VPORT or with VPORT-EDMA.

     

     

  • 0 in reply to Sivaraj R3681
    Intellectual 310 points

    Currently I am wondering if there might be some DMA conflict.

    Our algorithm processes at 10 fps, while the application captures at 30 fps.  So there are 3 FVID_exchange calls between calls to our algorithm.  I noticed that the error always first happens on the FVID_exchange call directly after our algorithm runs.

    So I bypassed the video driver and started feeding the algorithm directly.  It failed and got stuck in an ACPY3_wait() call.  I saw this a couple of times before, but I thought maybe the video driver was causing it, since the same algorithm library runs fine on DM6437 and DM6446.  But it looks like there is some DMA problem, and maybe the driver is getting wrecked by it.

    If it again starts looking like a driver problem, then I might have more questions.

    Of course, I still don't understand why the same library would have DMA issues on the DM648 but not on other c64x+ cores.

  • 0 in reply to chris2476
    TI__Expert 4935 points

    Chris,

    Are you aware of the Siicon bug "SDMA/IDMA : When DSP Level 2 memory is configured as non-cache (RAM), unexpected blocking and potential deadlock condition may occur"?

    Your problem could be related to this.

    Refer advisory 1.1.5 and 1.1.3 of http://focus.ti.com/lit/er/sprz263c/sprz263c.pdf

     

  • 0 in reply to Sivaraj R3681
    TI__Mastermind 41665 points

    While the SDMA/IDMA issue may play into the system, if the software was the same on the DM6437 as the DM648 than there must be something more than this errata, as this errata exists in some form on all C64x+ core devices I have seen (at least on DM6437 as well).

  • 0 in reply to Bernie Thompson TI
    Intellectual 310 points

    So after some serious debugging, I found that our software library was configuring an ACPY before the previous ACPY finished.  This collision resulted in the stall in ACPY_wait, and it was also throwing the video driver for a loop.  My theory is that the DM6437 and DM6446 both run slower, so on those processors, the troublesome ACPY configure didn't happen until after the DMA completed.  That is why I only saw the issue on DM648.

    Thanks for all the help. It really helped me zero in on the problem.

    Sorry I ever doubted the DM648 EVM video driver :).