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.

Issue with EDMA3

HI All,
 
We are using DM64x+ and EDMA3 resources with IRES interface for our application.
 

1] In that we are facing some issue with Transfer Controllers(TCs).

    Is anywhere we have to set a parameter for max number of TCs while requesting IRES?. we set parameter like maxTccs and maxParams and maxEDMA2channels, etc...

      Because when we use two TCs our application works fine, but when we use more than  two TCs our system hangs!!. (max TCs are 4.)

 

2] Is there any rule that we have to wait for DMA in the order we have triggered it?

 

    Consider the following two cases. In the second case, DMAs are triggered in order 1, 2, 3, 4 and waits in order 2, 4, 1, 3.

    So is the second case wrong?

 

    Case 1]

            DMA start 1

            DMA start 2

            DMA start 3

            DMA start 4

            ----DSP Processing--------

            DMA wait 1

            DMA wait 2

            DMA wait 3

            DMA wait 4

 

    Case 2]

            DMA start 1

            DMA start 2

            DMA start 3

            DMA start 4

            ----DSP Processing--------

            DMA wait 2

            DMA wait 4

            DMA wait 1

            DMA wait 3

 

3]   Consider the following case:
 
     we are using TC0 to  transferring data from DDR2  to L2 and TC1 is for all combination( like DDR2-L2,  L2-DDR2, L1-L2) is it OK or is going to give weird result?
 
 
Thank you,
Veeru
  • What processor?

    What version of Framework Components?

  • Hi

    We are using DM6467 processor and FC's version is 2.10.01

  • I would refer to the following wiki article

    http://wiki.davincidsp.com/index.php?title=DMA_Framework_Components#Configuring_DMAN3_Using_RTSC_Tooling

    it describes where to define DMA resources as well as details the different DMA APIs.

  • Some questions:-

    - Are you using the ti.sdo.fc.ires module to request DMA channels ?! or are you using DMAN3 ?

    - If you using ires, this means that you are using your own DMA library to perform the actual transfers. If this is the case, you should be setting up the registers DMAQNUM*, QDMAQNUM*, QUETCMAP etc Are you doing that ?

     

    To answer your specific questions:-

    1. If you are using ti.sdo.fc.ires, there is no need to set maxTCs etc, because any setting w.r.t TCs is assumed to be taken care of by the codec/applications' DMA library

    2. .The second case is not wrong, if the tranfers are independent, you don't have to wait in the same order that you triggered them.

    3. TC0 to transfer from DDR2 to L2 should be fine.TC1 for all combinations might be an issue. Could you try and distribute your transfers, so that TC1 -> DDR2-L2 TC2 -> L2-DDR2 TC3 -> L1-L2, to see if this works ?

     

  • Hi Gunjan,

    Thank you so much for your reply,

    Yes we are using IRES module to request DMA channels and we are setting DMAQNUM resister. I think QUETCMAP setting no need for us , by default it is one to one mapping.

    As you told different combination of transfers on single TC may create issue.. is this because of silicon errata ?, if so  our algoritm should  get hang, but it will not  produce inconsistent ouput. Is my understanding correct?

    when we use single TC for all combination transfer its working fine.  If we use two TCs, and different combination of tranfers on each TCs is creating missmatch issue.

    In our case we have 3 different memory ( L1, L2, DDR2)  and if we want use only 2 TCs, how to handle this case?

    thank you,

    Veeru

  • Veeru said:

    In our case we have 3 different memory ( L1, L2, DDR2)  and if we want use only 2 TCs, how to handle this case?

    I generally recommend a DMA allocation scheme where the small transfers go on one TC, e.g. TC1 and the long transfers go on a different TC, eg TC2.  Typically a short transfer such as servicing a serial port also has the most rigid real-time deadline.  Therefore you don't want that transfer to be queued behind a very long transfer because that can cause you to miss your deadline.