You are here

Tips and Tricks - DMA DRQ Itchy Trigger Finger | Cypress Semiconductor

Tips and Tricks - DMA DRQ Itchy Trigger Finger

Summary: 6 Replies, Latest post by danaaknight on 18 Aug 2015 04:09 PM PDT
Verified Answers: 0
Last post
Log in to post new comments.
dasg's picture
Cypress Employee
730 posts

How to prevent unwanted DMA transactions after enabling a DMA channel with queued transaction requests.

If a disabled DMA channel receives a request to perform a transfer, the request will be queued up similar to a pending interrupt.  When the channel is enabled, the pending transfer request will be executed, resulting in a transaction that may not be desired.

The workaround is to queue up a “terminate channel” request.  This request takes precedence over the transfer request.  As soon as the channel is enabled, the terminate request is executed instead of the transfer request.  This clears the pending transfer requests and disables the channel.  The channel must be re-enabled afterward to function as intended.

This problem was discovered when an ADC End Of Conversion (EOC) was connected to the DMA ReQuest (DRQ) terminal of a DMA channel.  The DMA channel was only really needed during a brief high speed sampling window.  The ADC would be used normally other times, with software requesting a start of conversion and the "conversion done" bit being polled by the CPU to determine when the conversion was complete.

It was observed that when the ADC was disabled and the DMA channel was turned on (enabled), a sample would mysteriously appear in RAM.  This was occurring even though it was guaranteed that the EOC signal was not asserted when the channel was enabled.

It was determined that when the ADC was used normally, the EOC was asserting the DRQ of the disabled DMA channel. This request was remembered by the DMA channel, even though the DMA channel was disabled.  When the channel was enabled, this "remembered" DRQ was being executed immediately, resulting in an unexpected DMA transfer.

The fix is to assert a CPU request to terminate the chain before enabling the channel.  By doing this, both requests (the transfer request and the terminate request) will be queued up in the DMA channel, waiting for the channel to be enabled.  When the channel is enabled, the terminate request will take precedence over the transfer request and the DMA channel will terminate immediately, erasing the pending transfer request.  The channel needs to be re-enabled after being enabled the first time since the terminate request will also disable the channel.

Below is example code, showing how the terminate request should be made before enabling the channel:

// Your DMA configuration code goes here
// --->
// ....
// <---
// End DMA config code

// To clear unwanted transfer requests (DRQ), issue a CPU terminate chain request
CyDmaChSetRequest(DMA_Channel, CPU_TERM_CHAIN);

// Enable the DMA channel, This enable kills the spurious DMA transaction if there is one
// and disables the channel, must re-enable
CyDmaChEnable(DMA_Channel, 1);

// re-enable the DMA channel
CyDmaChEnable(DMA_Channel, 1);

robertseczkowski's picture
127 posts

Are there timing requirements fullfilled?

DMA can run with BUS_CLK, but software terminate is much slower.

The article doesn't stress enough that ADC is a timig source.

Let's imagine SRAM to SRAM transfer using DMA with full speed. What now?

Now your discovery is called a BUG, because above solution will not work.

It would be much better to use a counter instead, and stop sending trq after count values.

But counter has 20MHz limit( or even less).

And again we have a BUG.

BUG means we can not run DMA with full speed unless we accept some disfunctions.


Robert Seczkowski

user_1377889's picture
9279 posts

That post at least shows a presumable source of errors. And it points out ONE way to circumvent this problem.


I wouldn't call that buggy, if there may be situations where that solution will not work.



Daniel_93745's picture
1 post

 Thanks for posting this.


The approach worked like a charm and saved me a very frustrating couple of days! ( I never would have worked out the underlying issue!)

user_14586677's picture
7646 posts

Keep in mind in the results tab of workspace explorer is a xx_timing.html

file you can look at clock rates achieved by the routes to get at actual values,

for example counters. You can see a max value allowed if configuration violates

your timing, that in turn will yield an entry in the max clock rate entry in table.


Regards, Dana.

user_193124556's picture
128 posts

Dana, is there any documentation on how to resolve timing issues with PSoC Creator? I'm familiar with timing and resolving issues in FPGAs but it doesn't seem that there is either enough control nor enough information in the timing report to help resolve timing issues.

user_14586677's picture
7646 posts

I am not aware of any, would not hurt to file a CASE and raise this issue.


To create a technical or issue case at Cypress -

“Design Support”

“Create a Support Case”


You have to be registered on Cypress web site first.


Regards, Dana.



Log in to post new comments.