• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 308 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.

DMA chaining on dm643x

MattLipsey
Genius 3575 points

I have been experimenting with the dma on the dm6435 using the simulator and have been able to successfully perform chained transfers.  Right now I have 2 dma channels.  Each dma channel has 2 link PaRAM sets associated with it to perform automatic ping pong buffering.  Since I have an input channel and an output channel, I chained them together so that the completion of the input transfer would trigger the start of the output transfer.  I enabled interrupt completion only for the out transfer, and make sure that the previous transfer has completed before triggering the next one.  I noticed that when I enable early transfer completion for the input channel that I receive a message from the simulator:

Error: TC Program set already active

I tinkered a little and found that if I set the out buffer to a different tc (transfer controller) that this error goes away.  It also goes away if I set the transfer completion to only occur when the whole transfer is completed.  I wanted to make sure this is expected behavior, ie I cannot "queue up" multiple channel events on the same transfer controller by performing chaining with early transfer completion.

btw, this code does not use any of the edma3 drivers.  Thanks in advance for any insight.

  • 0
    TI__Guru*** 125430 points

    For automatic ping-pong buffering you need to have 3 parameter sets:  1 that gets updated/modified by the Channel Controller (CC) and 2 for reloads.  Is that what you're doing?

    How are you going about changing the TC being used?  Was it through the DMAQNUMn registers?

  • 0 in reply to Brad Griffis
    Genius 3575 points

    Yes to both questions, although I think I have tracked down the error.  I update the source for the in xfer and destination for the out xfer immediately after triggering the first channel in the chain, and it is this step that is triggering the error.  I guess the difference between the two setups was just a subtle timing problem of updating a PaRAM set while it is being read by the TC.  I'll probably change to a pre-trigger increment of this values instead of a post trigger.  Sorry for the distraction, the error message was just cryptic enough that I wasn't sure what was causing it and had to dig through a few software layers to find out.