You are here

DMA BYTES_PER_BURST with varying TD Transfer_Count | Cypress Semiconductor

DMA BYTES_PER_BURST with varying TD Transfer_Count

Summary: 2 Replies, Latest post by willemite on 10 Sep 2014 05:21 PM PDT
Verified Answers: 0
Last post
Log in to post new comments.
user_22393527's picture
65 posts

 Hi all,

I've been poking around with DMA and learning quite a bit. In short I have a 32 bit counter with DMA that transfers the values to memory. This is done in two DMA channels because of the 16 bit spoke limitation and works just fine.

Then of course I decided to try adding another TD to the second channel. This one is chained to the end of the first (memory to memory 4 byte transfer) but is only 2 bytes long as I would like to transfer the results of a second counter at the same time.

I am going to assume this is foolish as it works only if it comes after the first TD (4 bytes followed by 2 bytes) but not if it goes first (2 bytes followed by 4 bytes). 

Does this mean I should use a separate channel for all DMA transfers that are varied widths?

BMAH's picture
Cypress Employee
189 posts


Firstly, could you let us know if you are transferring the 32 bit counter value to SRAM using "Intermediate Memory Location" method as described in

If I understand correctly, you would like to transfer the second counter value (2 bytes) during the second TD of the second DMA channel. What is the exact application? Would you to like to transfer the second counter's value after the first TD has been completed? If so, the method that you implemented should work fine. Let us know your exact requirement so that we can suggest the best solution.


PSoC Wonders 

user_22393527's picture
65 posts

That is correct, I am transferring the 32 bit value into an array via an intermediate memory location due the the spoke width constraints.

I suppose what I was thinking was that the trigger to transfer the 32 bit counter was the same as the trigger to transfer a separate 16 bit counter, and for efficiency perhaps I should just use a TD chained to the end instead of creating a separate channel.  I wanted to know when both were completed with a single event. 

From what i can work out, this works fine in my case because the channel releases if it terminates after sending a small transfer following a big transfer. In other words, if i transfer 4 bytes in one TD then 2 bytes in the next TD in the chain and release (sent the nrq line high), it works (this is a channel configured to 4 bytes per channel). But (clearly in retrospect) it does not work to do the 2 bytes then the 4 bytes because the channel does not release after the 2 bytes transaction.

I just changed to using 2 channels to avoid the issues....

Log in to post new comments.