Tips and Tricks - DMA DRQ Itchy Trigger Finger

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

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

Summary:
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.

Details:
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);

0 Likes
6 Replies
Anonymous
Not applicable

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.

   

Regards

   

Robert Seczkowski

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

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.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

 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!)

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

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.

0 Likes
Anonymous
Not applicable

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.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

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 -

   

 

   

www.cypress.com

   

“Design Support”

   

“Create a Support Case”

   

 

   

You have to be registered on Cypress web site first.

   

 

   

Regards, Dana.

0 Likes