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.

DMA Chaining on OMAP35xx

I've been trying to get DMA chaining working with no success.

Tested the DMA ("single shot") and it seems to work. I'm getting all the correct data dumped in the correct location. Getting a chained transfer to work sounds easy, I'm just following p.1027 in the TRM (Rev. C)

However, I'm not seeing it happening. I'm just seeing the target for the 1st DMA fill up with data.

In my test case, I'm using DMA channel 2 and channel 3, no particular reason, just picking them. Everything is setup to be non-synchronized (triggered by software).

These are the settings:

  • DMA4_CCR2 = 0x01005040
  • DMA4_CCR3 = 0x01005040 
  • DMA4_CLNK2 = 0x00008003
  • DMA4_CLNK3 = 0x00008002

So what I'm doing is just alternating between 2 DMA channels. Each of them go to a different location in memory. Then I kick off the DMA by writing to DMA4_CCR2 = 0x010050C0

I immediately read back DMA4_CCR2 and verified that this channel is enabled, and of course, I get data refreshed so I know it starts. Problem is it never goes to the 2nd DMA channel that I chained to.

I don't send a lot of data for testing, a very small amount, so it should have finished. In fact, I query DMA4_CCR2 and it is 0x01005040, so I assume it has automatically finished its transfer and handed off to the next one in the chain, which, unfortunately, doesn't seem to happen.

I tried different combinations, all pretty much the same thing. The lower DMA channel seems to take effect only. Individually, all the DMA channels seem to work ...

Is there something I'm missing here?

 

  • I think you've misunderstood the meaning of  "chaining" in the context of the SDMA.  It does not actually initiate that next transfer (as perhaps you're used to with EDMA).  In this case chaining merely enables the channel you tell it so it will actually require another event to trigger it.

  • Perhaps I don't understand it, maybe I'm looking in the wrong section of the TRM or trying to use the wrong feature.

    In TRM Section 1.4.10 Chained Logic Channel Transfers it says:

    "Chaining multiple logical channels permits transfers consisting of multiple parts to be executed without
    repeated software intervention
    ."

    And then under section 1.5.7 Chained Transfer, the instructions for setting it up are:

    "Enable the transfer via the enable bit in the first logical channel DMA register bit
    SDMA.DMA4_CCRi[7]. All other channels in the chain must be configured as disabled. Each channel
    is enabled automatically
    in turn when the previous logical channel transfer completes. A
    nonsynchronized transfer starts immediately..."

    Since this is under software synchronization (or non-synchronized in the TRM parlance), I initiate the start (enable) for the 1st logical channel via software. (i.e. just write to the register) as indicated above. And I see the DMA start, so that part must be happening correctly. Since the whole point of the chaining is to let it run without repeated software intervention, it would be logical to assume that once I start the 1st channel, the rest will enable themselves in the proper sequence, yes?

  • Sorry, perhaps I'm the one who doesn't quite get it!  In the past I've not used a non-synchronized transfer so I must have missed/forgotten that aspect of it.  You're right...  Of course that doesn't resolve your issue.

    Are you trying to make these channels run in a forever loop?  If not, I think you need to disable the link feature on channel 3 or else it will/should restart channel 2.

    What did you mean earlier when you said you tested them "single shot"?  Are you saying that you can disable the link feature in both of them and if you enable them one at a time then both of them work as you expect?  If that's not what you meant, can you please try that?

     

  • I've got the OMAP setup to read from an FPGA device via the GPMC bus using the sDMA to transfer the data.  I'm doing Hardware-Synchronized Transfers, so the DMA is being triggered by the FPGA to transfer 4096 bytes for every trigger event.  I'm also making use of the DMA chaining feature to dump the data into two different destination memory locations, buffer A and buffer B, respectively.  So what I've got so far is, 4096 bytes from transfer #1 is going to buffer A and 4096bytes from transfer#2 is going to buffer B, simple enough.  However, what I would really like to accomplish is to fill up one buffer, buffer A with first 100 consecutive transfers (total of 400kB) to go into buffer A, and the next 100 transfers (400kB) go into buffer B, then repeat this sequence indefinitely (soft of ping-pong approach).  I have not been able to find a way to configure the sDMA to do such a thing.  I would like to keep SW interactions in the middle of the DMA transfers to a minimum. 

    Is this possible to do within the DMA module itself?

     

  • Joe Joe: That should be possible by using both of DMA4_CFNi and DMA4_CENi.  The TRM section 9.4.3 (in SPRUF98T, but it should be the same section number in earlier revisions) discusses how a single DMA channel describes a "block" transfer, consisting of some number of "frames", each composed of a fixed number of "elements".  You should get the results you want with DMA4_CFNi=100 and DMA4_CENi=4096.

    If each 4096-byte frame should start at the same address on the GPMC bus, I think you will also need to use double-index addressing for the source side with EI=1 and FI=-4095.

    [I edited out a bit here due to not noticing earlier that Joe Joe was different than the original poster.  I am not sure why IsaacLeung would not be seeing the chained transfer working; the "Software-Triggered (Nonsynchronized) Transfer" and "Chained Transfer" examples in TRM section 9.5 say they should work.  Maybe one of the other control registers for channel 3 is not right?  What happens if you enable channel 3 first?  When the second transfer does not occur, do the values of DMA4_CCR2/3's WR_ACTIVE or RD_ACTIVE bits, or the values of DMA4_CSACi, DMA4_CDACi, DMA4_CCENi and DMA4_CCFNi suggest where or why it is stopping?]