• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 104 subscribers
  • Views 1189 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Concerning EDMA Linking

David Aldrich92784
Genius 3720 points

I have a question about using EDMA on the K2H device.

We are trying to implement a sequence of EDMA transfers using one EDMA channel and several link PaRAM sets, using linking and chaining. The idea is that the first PaRAM set copies data from L2 memory into another PaRAM set (actually a block of consecutive PaRAM sets), and then links to this PaRAM set in order to execute it. So this first PaRAM set looks like this:

 

prm->opt = 0x82418000;

prm->srcAddr = L2Addr;

prm->destAddr = PaRAMAddr;

prm->aCnt       = 160;

prm->bCnt       = 1;

prm->cCnt       = 1;

prm->bCntReload = 0;

prm->srcBIdx    = 0;

prm->destBIdx   = 0;

prm->srcCIdx    = 0;

prm->destCIdx   = 0;

prm->linkAddr   = (0xFFFFu) & PaRAMAddr;

 

Here L2Addr is an address in L2 memory corresponding to the head of a (potentially long) queue of PaRAM set parameters which have been prepared by the CPU. The idea is that to serve the next job on the queue, the CPU updates srcAddr in the above and then triggers the EDMA manually. The TCCHEN bit is set and TCC is set to chain to itself.

 

When we try this, what seems to happen is that the EDMA above executes successfully but the link to PaRAMAddr does not work. However we have found that if we modify prm->linkAddr in the above to link instead to the following dummy PaRAM set, which in turn links to PaRAMAddr, then it works.

 

prm->opt = 0x82418000;

prm->srcAddr = NULL;

prm->destAddr = NULL;

prm->aCnt       = 1;

prm->bCnt       = 0;

prm->cCnt       = 0;

prm->bCntReload = 0;

prm->srcBIdx    = 0;

prm->destBIdx   = 0;

prm->srcCIdx    = 0;

prm->destCIdx   = 0;

prm->linkAddr   = (0xFFFFu) & PaRAMAddr;

 

Is there a reason why this dummy transfer is needed? For example, is it illegal for destAddr and linkAddr in one PaRAM set to be the same?

  • 0
    TI__Mastermind 20790 points

    Hi,

    Link Address:
    The 16-bit parameter LINK specifies the byte address offset in the PaRAM from which the EDMA3CC loads/reloads the next PaRAM set during linking.
    You must program the link address to point to a valid aligned 32-byte PaRAM set. The 5 LSBs of the LINK field should be cleared to 0.

    You should make sure to program the LINK field correctly, so that link update is requested from a PaRAM address that falls in the range of the available PaRAM
    addresses on the device.

    Dummy Transfer:
    A dummy set results in the EDMA3CC performing a dummy transfer. This is not an error condition. A null set results in an error condition. A link update occurs for dummy transfers depending on the state of the STATIC bit in OPT and the LINK field. A dummy transfer is a legal transfer of 0 bytes.

    Please refer the test code at the below wiki page,
    http://processors.wiki.ti.com/index.php/EDMA_sample_test_application

  • 0 in reply to Pubesh
    Genius 3720 points
    Hi Pubesh

    We have read the user guide but we do not think that it answers this question.

    Let me try to make it clearer. We are working with 3 link PaRAM sets as follows.

    EDMA3_DRV_PaRAMRegs* prmSet1 = (EDMA3_DRV_PaRAMRegs*) 0x272f200;
    EDMA3_DRV_PaRAMRegs* prmSet2 = (EDMA3_DRV_PaRAMRegs*) 0x272f2e0;
    EDMA3_DRV_PaRAMRegs* prmSet3 = (EDMA3_DRV_PaRAMRegs*) 0x272f360;

    These are all valid link PaRAM set addresses. The 5 LSBs are all zero and the 16 MSBs are the same.

    With the following settings, everything works correctly (prmSet2, prmSet3 and prmSet1 all execute in sequence).

    prmSet2->opt = 0x82418000;
    prmSet2->srcAddr = L2Addr;
    prmSet2->destAddr = (uint) prmSet1;
    prmSet2->aCnt = 160;
    prmSet2->bCnt = 1;
    prmSet2->cCnt = 1;
    prmSet2->bCntReload = 0;
    prmSet2->srcBIdx = 0;
    prmSet2->destBIdx = 0;
    prmSet2->srcCIdx = 0;
    prmSet2->destCIdx = 0;
    prmSet2->linkAddr = (0xFFFFu) & (uint) prmSet3;

    prmSet3->opt = 0x82418000;
    prmSet3->srcAddr = NULL;
    prmSet3->destAddr = NULL;
    prmSet3->aCnt = 1;
    prmSet3->bCnt = 0;
    prmSet3->cCnt = 0;
    prmSet3->bCntReload = 0;
    prmSet3->srcBIdx = 0;
    prmSet3->destBIdx = 0;
    prmSet3->srcCIdx = 0;
    prmSet3->destCIdx = 0;
    prmSet3->linkAddr = (0xFFFFu) & (uint) prmSet1;

    However the following settings do not work. Only prmSet2 executes. (Note that prmSet3 is not used in this case).

    prmSet2->opt = 0x82418000;
    prmSet2->srcAddr = L2Addr;
    prmSet2->destAddr = (uint) prmSet1;
    prmSet2->aCnt = 160;
    prmSet2->bCnt = 1;
    prmSet2->cCnt = 1;
    prmSet2->bCntReload = 0;
    prmSet2->srcBIdx = 0;
    prmSet2->destBIdx = 0;
    prmSet2->srcCIdx = 0;
    prmSet2->destCIdx = 0;
    prmSet2->linkAddr = (0xFFFFu) & (uint) prmSet1;

    We cannot understand why the first case works but the second case does not work. The fact that the first case works proves that prmSet2 can successfully link to prmSet3, and that prmSet3 can successfully link to prmSet1. So why can't prmSet2 link to prmSet1?

    Best regards

    David
  • 0 in reply to David Aldrich92784
    TI__Genius 14680 points

    David,

    Please confirm you have true completion set and not early completion for the tcc. This affects when the sync event is triggered. Early completion is for transfer pipelining and will trigger before the data lands. True completion is gated by the final write cometion.

    Best regards,

    Dave

  • 0 in reply to Dave Bell
    Genius 3720 points
    Hi Dave

    I can confirm that we set TCCMODE to 0 ( i.e. ‘normal completion’ ).

    BR

    David
  • 0 in reply to David Aldrich92784
    TI__Guru* 78475 points

    Looks to me that you are exploring a somewhat corner case of  "linking to self" with link = self. Will need to dig through design specs to see if this is ok. 

    What happens if you try your failing scenario with OPT.STATIC set to 1?

    Regards

    Mukul 

  • 0
    TI__Expert 6815 points
    Dave,
    Like was said in earlier posts, this is probably a corner case and it remains to be seen if it is valid operation. We will investigate.
    That said, do you see any error conditions flagged in the missed/secondary registers for the single Param scenario?
    Also when you say "the EDMA above executes successfully" for the 2-Param case, I assume you see the desired content in the destination (in this case the paramset).
  • 0 in reply to Aditya
    Genius 3720 points

    Aditya

    > What happens if you try your failing scenario with OPT.STATIC set to 1?


    We tried changing the OPT setting to prmSet2->opt = 0x82418008 but the behaviour is still the same.

    > Also when you say "the EDMA above executes successfully" for the 2-Param case, I assume you see the desired content in the destination (in this case the paramset).

    We mean that the EDMA programmed in prmSet1 executed successfully, ie. the memory at prmSet1->destAddr contains the expected data. In the failure case, the prmSet1 parameters seem to be copied to the link PaRAM (ie. address 0x272f200 contains the correct prmSet1 parameters) but the linking seems to fail, so prmSet1 is not executed.

    David

  • 0 in reply to David Aldrich92784
    TI__Guru* 78475 points
    Ok, still hard to visualize :), perhaps confirmation that no error conditions are flagged in failing case and prmset1 memory dump in failing and passing case will help. It would appear that prmset2 content is fine and contains prmset1 values (as transferred from L2) but just the prmset2 didn't trigger a transfer again, so a trigger event did not happen?
    Can you double check that TCC value in failing case is as expected ?
  • 0 in reply to Mukul Bhatnagar
    Genius 3720 points
    It is difficult for us to perform any more tests at the moment. Meanwhile please could you check with the designer if the EDMA can support the case that the destAddr and linkAddr of a link PaRAM set point to the same memory location. Also you might want to try your own experiment. If there is a problem with this mode of operation then we think that you should be able to reproduce the problem easily.
  • 0 in reply to David Aldrich92784
    TI__Guru* 78475 points
    Hi David
    Thanks. Yes we will try to reproduce this here and also check with EDMA design team. The EDMA design team is out of office due to holiday week, so please expect delay in response. We will keep you posted.

    Regards
    Mukul
  • 0 in reply to David Aldrich92784
    TI__Expert 6815 points
    David,
    I discussed this with the design experts and the behavior you see is expected. When the EDMA submits the transfer request (TR) for the PaRAM, it uses the link PaRAM contents present at the time the TR is submitted. For the single PaRAM case, the PaRAM is "empty" at the time of transfer request so no linking takes place (it gets written when the TR is complete, but it is too late by that time).
    Inserting a second dummy transfer resolves this issue because the original writes to PaRAMAddr should already have landed from the first transfer and thus will link correctly when the dummy transfer is executed via the chain completion trigger.
  • 0 in reply to Aditya
    Genius 3720 points
    Hi Aditya

    Thanks very much for your answer. That is enough for us. We just wanted to make sure that we weren't doing anything wrong.

    Best regards

    David