DMA request queue

[luke2]

Posted on April 09, 2015 at 06:10

Hi all,

I am working on an STM32F0 project in which I am triggering a DMA transfer using peripheral events such as an input capture. Looking over the docs it seems a little vague as to the behaviour of the DMA controller in response to events that occur whilst a DMA transfer is currently in progress on the same channel. In my particular scenario I am initiating a DMA transfer using an input capture on the first edge of a GPIO. On the first edge, a set number of bits are transferred from the port. Since the capture and data signal are on the same line, the capture event should trigger only a single DMA transfer for a specified number of clock ticks, then be immediately ready for another trigger as soon as the transfer is complete. Since there will generally be multiple edge triggers during data transfer they should obviously not interfere with the behavior of the DMA transfer in progress. My confusion is regarding how the DMA controller behaves when it receives these extra DMA events while it is already servicing a DMA transfer on that channel - will it simply ignore them, or is there some sort of queue system per channel that will lead to additional transfers after the first is complete? The manual seems to indicate there might be some sort of queue going on: ''If there are more requests, the peripheral can initiate the next transaction.''Presuming this is true, what is its behavior (i.e. is it a simple counter) and can it be controlled in software? #stm32f0-dma-cc

[Tesla DeLorean]

Posted on April 09, 2015 at 06:32

''If there are more requests, the peripheral can initiate the next transaction.''

Like the USART/SPI has moved the holding register into the shift register and signals it wants to be replenished. Or the TIM hits the next CC1 point, and a new one gets loaded. Or the SDIO transfer length hasn't been met yet. If there is a signal saying a DMA action is pending, the DMA will service it until it stops pending. I would anticipate i fyou have multiple competing sources, they will OR together, or be latched in a manner that's not wholly ideal. Changing the source on the fly is likely to result in race or instability issues. Pretty sure there isn't a ''queue'' in the way you're envisioning one.

[luke2]

Posted on April 09, 2015 at 08:55

Thanks clive, that is helpful. I'm moving away from this solution as it seems difficult to get the DMA behavior right. Apparently pending requests are essentially a flip-flop on the timer and can be disabled by resetting the DMA event active bit, although this behavior just doesn't quite cut it for my purposes.