• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 97 subscribers
  • Views 394 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.

EDMA bandwidth issue

Elron A Yellin
Expert 1040 points

I'm using EDMA0 to move data between DSP L1D and McASP.  It works fine until I start doing some one-shot transfers with EDMA1 between EMIF and DDR.  Once these EDMA1 transfers start, I get a McASP Tx underrun.

from http://processors.wiki.ti.com/index.php/OMAP-L1x/C674x/AM1x_SoC_Architectural_Overview

"For uniquely exclusive master/slave pairs, concurrent transactions can be sent in parallel through and SCR."

lead me to believe that these two sets of transfers should be independent of each other.

Is there in fact some shared resource, or is something subtler going on?

Thanks,

Elron

  • 0
    TI__Guru* 83885 points

    Yes there is a shared resource in terms of bridge BR4 and BR3 (Between SCR1 and SCR2) where the commands and read/write data get buffered for read/write requests from TCs to McASP and EMIFA.

    So these are not truly independent paths.

    If your EDAM1 transfers were from Shared RAM to DDR , EDMA0 transfers were from L1D to McASP, those would be independent paths.

    Hope this helps

    Regards

    Mukul

  • 0 in reply to Mukul Bhatnagar
    Expert 1040 points

    Thanks.  Too bad all peripherals are on the opposite side of BR3-4 from all EDMA and all memory.  Maybe I can use the PRU...

  • 0 in reply to Elron A Yellin
    TI__Guru* 83885 points

    I think you need to investigate if your one shot transfer can be broken up in smaller chunks so the bridges allow better interleaving. Additionally you can see if throttling data can help on the EMIFA.

    Make sure that the TC priority for Que/TC servicing the McASP is at higher priority then the TC servicing the EMIFA/DDR. It is likely that you have already seen the tuning knobs possible. All of these might be still easier to further pursue compare to moving to PRU.

  • 0 in reply to Mukul Bhatnagar
    Expert 1040 points

    Thanks for the advice, but the priorities are already set up to favor the McASP, and the EMIF transfers are already only 2 bytes in the first dimension (and no 2D->1D coalescing is possible).  I did have some luck going the other way though, making the McASP transfers larger and fewer by bumping NUMEVT in the FIFO.  At least with the current amount of EMIF traffic, the DMA is keeping up with McASP.