• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 342 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.

TDA4VM: C7x UDMA DRU channel waits indefinitely for __EFR event in copy mode 2

Amine Hamidi
Prodigy 135 points
Part Number: TDA4VM

SDK Version: ti-processor-sdk-rtos-j721e-evm-08_06_00_12

DMA Driver: vision_apps/utils/udma

Hi,

I was implementing the following scenario using a couple of DRU channels:

  • STEP1: Initialise 1st DRU channel using "appUdmaCopyNDGetHandle".
  • STEP2: Initialise 2nd DRU channel using "appUdmaCopyNDGetHandle".
  • STEP3: for N iterations: 
    • STEP3_1: Copy srcBuffer1 to dstBuffer1 using 1st channel using "copy_mode" 0.
    • STEP3_2: Copy srcBuffer2 to dstBuffer2 using 2nd channel using "copy_mode" 0.
    • STEP3_3: Copy srcBuffer3 to dstBuffer3 using 1st and 2nd channels in ping_pong using "copy_mode" 2.
  • STEP4: DeInitialise 1st DRU channel using "appUdmaCopyNDReleaseHandle".
  • STEP5: DeInitialise 2nd DRU channel using "appUdmaCopyNDReleaseHandle".

During the execution of STEP3_3, DRU channels seems to randomly hung and wait indefinitely for __EFR event.

This issue only happens in STEP3_3 and only when we switch to copy_mode 2.

Regards.

  • 0
    Prodigy 135 points

    Hello, 

    A followup on my previous comment.

    Whe the DRU channel randomly hungs, the __EFR event register value is allways 0 and no event is reported.

    The value is retreived using:

    volatile uint64_t eflRegisterVal  =  __get_indexed(__EFR,0);
    Regards
  • 0 in reply to Amine Hamidi
    Prodigy 135 points

    Hello, 

    A followup on my previous comment.

    In the "appUdmaTrpdInit" function located in "vision_apps/utils/udma/src/app_udma_utils.c" file, we added the following modifications:

    For copy_mode 0:

    • Set the UDMAP_TR_FLAGS_TRIGGER0 to CSL_UDMAP_TR_FLAGS_TRIGGER_GLOBAL0
    • Set the UDMAP_TR_FLAGS_EOL to CSL_UDMAP_TR_FLAGS_EOL_MATCH_SOL_EOL

    Below is the code:

     if(copy_mode == 0)
    {
        // pTr->flags |= CSL_FMK(UDMAP_TR_FLAGS_EVENT_SIZE, CSL_UDMAP_TR_FLAGS_EVENT_SIZE_COMPLETION);
        // pTr->flags |= CSL_FMK(UDMAP_TR_FLAGS_TRIGGER0, CSL_UDMAP_TR_FLAGS_TRIGGER_NONE);
        // pTr->flags |= CSL_FMK(UDMAP_TR_FLAGS_TRIGGER0_TYPE, CSL_UDMAP_TR_FLAGS_TRIGGER_TYPE_ALL);
        pTr->flags |= CSL_FMK(UDMAP_TR_FLAGS_EVENT_SIZE, CSL_UDMAP_TR_FLAGS_EVENT_SIZE_COMPLETION);
        pTr->flags |= CSL_FMK(UDMAP_TR_FLAGS_TRIGGER0, CSL_UDMAP_TR_FLAGS_TRIGGER_GLOBAL0);
        pTr->flags |= CSL_FMK(UDMAP_TR_FLAGS_TRIGGER0_TYPE, CSL_UDMAP_TR_FLAGS_TRIGGER_TYPE_ALL);
        pTr->flags |= CSL_FMK(UDMAP_TR_FLAGS_EOL, CSL_UDMAP_TR_FLAGS_EOL_MATCH_SOL_EOL);
    }
    else if(copy_mode == 1)
    {....

    This seems to fix the issue for the switch between copy mode 0 and 2, however we would like a confirmation from TI's side.

    Regards

  • 0 in reply to Amine Hamidi
    TI__Guru**** 475655 points

    Unlocking this ticket.