DMA from stack, why not?

[root]

Posted on August 20, 2013 at 20:03

Hello,

I was writting a driver for SPI transfer using double DMA ... to test it I wrote a few lines of code that prepared a buffer (locally), and sent it over SPI. The result was the first 4 bytes were ok then the data was totally corrupted. I searched the forum and found this post from our hero, Clive :

/f578fd6e

Tested with a buffer not declared locally (so not on the stack) and it's working as expected (no data corruption). So now my question is simple ... why ? Thomas.

[Tesla DeLorean]

Posted on August 20, 2013 at 20:59

My general distrust of doing DMA to the stack is simply that it is temporal, and if the DMA request outlives the stack frame all manner of unexplained behaviour can occur. I've worked on asynchronous IO drivers in the past, if the work isn't finished you're expected to leave immediately and be called back later, often in a wholly different context. Stacks there are inherently a bad place to put things, and static buffers within functions are not thread safe.

You also want it to be volatile, and not committed to registers by the optimizer. Probably not an issue for larger buffers. Of the other issues that come to mind, one has to be mindful of the alignment, it should be 4 or 8 byte aligned, the other is that if the stack is parked in CCM then it's not DMA accessible. Another potential pitfall is the size measured in DMA units, not bytes. Static buffers are also a lot easier to mark/guard, and view in the debugger by name regardless of current scope. Some of the STM32 permit ''double-buffered'' DMA (means something else on Win PCs), I have generally avoided this for linear buffers which can do ping-pong operations with HT/TC interrupts. If the buffers were sparse or chained I could see some utility in describing different memory regions, and sequencing them.