<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>DMA Transfer Patterns on Embedded Systems Development</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/dma/</link><description>Recent content in DMA Transfer Patterns on Embedded Systems Development</description><generator>Hugo</generator><language>en-us</language><atom:link href="https://applied-ee.github.io/embedded/docs/digital-interfaces/dma/index.xml" rel="self" type="application/rss+xml"/><item><title>DMA Channel &amp; Stream Architecture</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/dma/dma-channel-architecture/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/dma/dma-channel-architecture/</guid><description>&lt;h1 id="dma-channel--stream-architecture"&gt;DMA Channel &amp;amp; Stream Architecture&lt;a class="anchor" href="#dma-channel--stream-architecture"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;DMA controllers move data between peripherals and memory without CPU involvement, but the internal routing between a peripheral request and the DMA hardware that services it varies significantly across MCU families. Getting the mapping right is a prerequisite — configuring the wrong stream or channel produces no transfer and no error flag, just silence on the bus.&lt;/p&gt;
&lt;h2 id="stm32f4-streams-channels-and-fixed-mapping"&gt;STM32F4: Streams, Channels, and Fixed Mapping&lt;a class="anchor" href="#stm32f4-streams-channels-and-fixed-mapping"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;The STM32F4 has two DMA controllers (DMA1 and DMA2), each with 8 streams (0–7). Each stream has a channel multiplexer that selects one of 8 channel inputs (0–7). The combination of controller, stream, and channel determines which peripheral request is serviced. These mappings are fixed in silicon and listed in the reference manual (RM0090, Table 42/43).&lt;/p&gt;</description></item><item><title>Memory-to-Peripheral &amp; Peripheral-to-Memory</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/dma/dma-transfer-directions/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/dma/dma-transfer-directions/</guid><description>&lt;h1 id="memory-to-peripheral--peripheral-to-memory"&gt;Memory-to-Peripheral &amp;amp; Peripheral-to-Memory&lt;a class="anchor" href="#memory-to-peripheral--peripheral-to-memory"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Every DMA transfer has a source, a destination, and a set of rules governing how addresses advance and how data widths are matched. The three fundamental directions — peripheral-to-memory, memory-to-peripheral, and memory-to-memory — cover nearly every use case in embedded firmware. Getting the direction, increment mode, or data alignment wrong produces transfers that appear to work but deliver corrupted or shifted data.&lt;/p&gt;
&lt;h2 id="transfer-directions"&gt;Transfer Directions&lt;a class="anchor" href="#transfer-directions"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;DMA direction is configured from the perspective of the DMA controller:&lt;/p&gt;</description></item><item><title>Circular &amp; Double-Buffer Modes</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/dma/dma-circular-double-buffer/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/dma/dma-circular-double-buffer/</guid><description>&lt;h1 id="circular--double-buffer-modes"&gt;Circular &amp;amp; Double-Buffer Modes&lt;a class="anchor" href="#circular--double-buffer-modes"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Single-shot DMA transfers work for one-time operations like sending a command over SPI, but continuous data streams — ADC sampling, audio I/O, sensor logging — require the DMA controller to keep running indefinitely. Circular mode and double-buffer mode solve this by automatically reloading the transfer and providing mechanisms to process completed data without stopping the stream.&lt;/p&gt;
&lt;h2 id="circular-mode"&gt;Circular Mode&lt;a class="anchor" href="#circular-mode"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;In circular mode, the DMA stream automatically reloads the transfer count (NDTR) and resets the memory pointer to the buffer base address when the current transfer completes. The stream never stops — it wraps around to the beginning of the buffer and continues filling.&lt;/p&gt;</description></item><item><title>Cache Coherency &amp; DMA on Cortex-M7</title><link>https://applied-ee.github.io/embedded/docs/digital-interfaces/dma/dma-cache-coherency/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/digital-interfaces/dma/dma-cache-coherency/</guid><description>&lt;h1 id="cache-coherency--dma-on-cortex-m7"&gt;Cache Coherency &amp;amp; DMA on Cortex-M7&lt;a class="anchor" href="#cache-coherency--dma-on-cortex-m7"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Cortex-M7 processors (STM32F7, STM32H7) include separate instruction and data caches — typically 16 KB I-cache and 16 KB D-cache — that dramatically improve execution speed by reducing access latency to main SRAM. But DMA controllers operate on the physical bus, bypassing the CPU cache entirely. When DMA writes data to SRAM, the CPU cache may still hold stale values at those addresses. When the CPU writes data that DMA will read, the cache may hold updated values that have not been flushed to SRAM. This coherency problem is the single most common source of intermittent, hard-to-diagnose data corruption on Cortex-M7 systems.&lt;/p&gt;</description></item></channel></rss>