DMA Double Buffer Problem

[roland]

Posted on June 27, 2013 at 13:04

The original post was too long to process during our migration. Please click on the attachment to read the original post.

[roland]

Posted on July 09, 2013 at 17:38

Hi,

I found a bug in the code that I posted above.

In 

DMA1_Stream3_IRQHandler, 

the line

if (DMA_GetITStatus(DMA1_Stream3, DMA_FLAG_TCIF3) == RESET)

should be

if (DMA_GetITStatus(DMA1_Stream3, DMA_IT_TCIF3) != RESET)

to actually check for the correct interrupt status.

It seems a common mistake to mix the usage of 

DMA_FLAG_TCIF3 

and 

DMA_IT_TCIF3.

However, this doesn't solve the problem, that the buffer is not switched

automatically. Any ideas?

Kind regards,

Roland

[andprice]

Posted on August 08, 2013 at 23:58

I'm configuring DMA almost identically and I'm having a similar issue.  The documentation is really unclear.  As far as I can tell, you're supposed to get a transfer complete interrupt when NDTR (BUFFERSIZE in your example) has reached 0.  Now I would assume that the sequence would be:

1) Start DMA

2) NDTR reaches 0

3) CT=1, DMA writes to M1AR (done in HW)

4) NDTR reloaded to BUFFERSIZE

5) TCIF set (and you get the interrupt)

6) Now you can mess with buf[0]

7) NDTR reaches 0

8) CT=0, DMA writing to M0AR

9) NDTR reloaded to BUFFERSIZE and you get TCIF interrupt

10) Mess with buf[1]

However, this isn't the behavior I see.  I suspect there's probably a half-transfer complete interrupt that we should be using.

BTW, printf inside an ISR is generally a bad idea.  You might want to consider toggling a GPIO and using a scope.

[roland]

Posted on October 20, 2014 at 14:58

Hi Andrew,

thank's for your reply, ... already some time ago.

The project hibernating for some time and I didn't check the forum since then.

But now I'm coming back to this topic. And I'm wondering, if you or anyone else has found a solution to the double buffered DMA transfer...

If so, please let me know.

Cheers, Roland

[Tesla DeLorean]

Posted on October 20, 2014 at 18:43

Yeah, I really don't want to wade into this too deeply, but you should probably confirm if any SPI activity is occurring. To Rx there usually needs to be some Tx activity to generate clocking.

[waclawek.jan]

Posted on October 20, 2014 at 22:05

> To Rx there usually needs to be some Tx activity to generate clocking.

Clive: Isn't this the odd case of receive-only setup?

Roland: As was said above, get rid of the printf(). Find some other way to indicate the even/odd buffer: toggle a pin and observe it with an oscilloscope.

JW

[Tesla DeLorean]

Posted on October 21, 2014 at 01:35

Clive: Isn't this the odd case of receive-only setup?

I don't have enough mileage around this edge of the design to really know, one might hope, but if the DMA isn't completing I'd want to be sure any of the DMA/Transfer is occurring.