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.

Unexpected chain-event of EDMA

Other Parts Discussed in Thread: TVP5158

Hi there,

I am integrating a multi-channel DVR using DM365 (voice codec applied) and TVP5158.
The DVR (Voice/TVP5158 capture & H264 encode) can work repeatedly (create,free,create,free...) fine.
The PLAYBACK (Voice/VPBE output & H264 decode) also can work repeatedly fine.
However the inter-operability test (DVR->PLAYBACK->DVR->PLAYBACK->...) fails in the 2nd round DVR in capture.

For TVP5158 capture, EDMA channel 4 (EDMA_VPSS_EVT1) is allocated for manually-initiated DMA.
PaRAM #66 and beyond 94sets are allocated for chain-triggered DMA following the manual initiation.
I am sure EDMA channel 4 and all PaRAM sets are freed after the last (normal) completion, ISIF is disabled, and then TVP5158 is disabled.
PLAYBACK doesn't apply EDMA channel 4 but the reason the 2nd round DVR fails in capture is CER.E4 and SER.E4 get asserted right after TVP5158 is enabled.

How to identify the source of this undesired chain event and get rid of it ?
What are the reasons that CER.E4 and SER.E4 get asserted unexpectedly after a 10seconds of irrelative PLAYBACK
instead of asserted and stopping the 2nd round DVR in the repeated DVR test ?

Thanks in advance!

  • Yulin,

    Just to understand, are you using TI's DVR Reference Design or have you implemented the TVP5158 driver on your own? Meanwhile, i have redirected your question to the right person and would let you know the answer soon.

    Regards,

    Anshuman

     

  • hi Yulin,

    Are you using TI's TVP5158 driver or your own driver ?

    We havent seen this issue in TI's TVP5158 driver on DM36x ?

    How do you allocate EDMA CHs, can you send you EDMA programming code snippet/file so that we can see if you are missing anything ?

    You meationed voice codec applied, does having or not having voice codec make the behviour any different ?

    thanks and regards
    Kedar

     

  • Anshuman,

    I am not using TI's DVR Reference Design and
    the TVP5158 driver is our own design with some reference/reuse of MCVIP v010011_0090909.

    Thank you for responding.

    Yulin.

  • Hi Kedar,

    I am using our own TVP5158 driver.

    Could you please provide your e-mail address for me to send you our EDMA driver (proprietary RTOS based).

    Do you mean to disable all audio-capture/encode and audio-decode/output ?

    Thanks for responding.

    Yulin

  • hello Yulin,

    You can send the EDMA code to kedarc@ti.com

     

    regards

    Kedar

     

  • hello Yulin,

     

    I was not able to fully review the EDMA code, but looks like EDMA state is not in clear state when you switch from playback to DVR encode mode.

    Can you try clearing all bits in EDMA related to error, interrupt status when you switch form playback to DVR encode mode?

     

    regards

    Kedar

  • Hi Kedar,

    Yes, that is a workaround to make EDMA of MCVIP to continue but not a good solution.
    The major concern is to get rid of the reason that cause CER.E4 to be asserted or this issue very likely occurs again in some other place
    every time I try to integrate more features/operations.

    BR,
    Yulin

  • Maybe some linked PaRAM entry is setting CH4 as its chaining event.

    Can you try moving the MCVIP EDMA channel from CH4 to some other channel ?

    ~Kedar

  • Hi Kedar,

    Following your tip, I tried:

    1. Right before McVIP releases EDMA channels, clear OPT of all PaRAM sets that McVIP obtained.
       Find TCC=4 in all 256 PaRAM sets after EDMA channels are released. --> NONE
       Find TCC=4 in all 256 PaRAM sets before McVIP allocates EDMA channels. --> NONE

    2. Along with the above procedures, I use some other channel instead of CH4.

    Both of the above 2 trials can not fix this issue.
    Do I follow your guidance precisely ?
    Or any idea to share ?

    ~Yulin.