【STM32 Series #10】The DMA Idea — Understanding the Transfer Architecture That Makes the CPU Idle

In the previous Episode 9 we learned “never put heavy processing inside an ISR.” But what do you do when you absolutely must transfer a large amount of data?

The answer is DMA (Direct Memory Access).

DMA is hardware that moves data without involving the CPU. The transfer completes while the CPU is free to do other things.

Table of Contents

1. What Is DMA?
2. Why Do We Need DMA?
3. STM32’s DMA Architecture
4. DMA-ifying UART TX (Practice)
5. Throughput and Latency
6. Bus Contention
7. Common Pitfalls
8. Summary

🔌 What Is DMA?

DMA Is a “Dedicated Data-Transfer Hardware Unit, Separate from the CPU”

DMA (Direct Memory Access) is a hardware module that exists independently from the CPU. It is not a memory feature, nor a CPU feature — it is an independent data-transfer engine connected to the bus.

Let’s first see what happens without DMA.

Data Transfer Without DMA

Consider the operation “send a string stored in RAM over UART.”

【Normal Transfer: The CPU Does Everything】

RAM (string buffer)
  │
  │ LDR instruction (CPU reads 1 byte from RAM)
  ▼
CPU (holds data in a register)
  │
  │ STR instruction (CPU writes 1 byte to UART DR register)
  ▼
UART DR register → physically transmitted

Sending 1 byte requires one “LDR → STR” CPU instruction pair. To send 100 bytes, the CPU repeats this 100 times. During that time the CPU can do nothing else.

With DMA

【DMA Transfer: CPU Just Places the Order】

CPU: "DMA, take 100 bytes from this address and send them to UART DR"
  │
  │ (CPU immediately moves to the next task)
  ▼
DMA controller (runs independently)
  │
  ├─ RAM → DMA → UART DR (byte 1)
  ├─ RAM → DMA → UART DR (byte 2)
  ├─     …… (CPU not involved)
  └─ RAM → DMA → UART DR (byte 100) Done!
           │
           └─ Transfer-complete interrupt notifies CPU

The CPU only “places the order,” and is then free to run.

Do All Microcontrollers Have DMA?

No. The presence or absence of DMA varies significantly by microcontroller.

One reason the Arduino UNO can only do blocking transmissions is that it has no DMA. 32-bit microcontrollers like the STM32 ship with DMA as standard.

What Is a “Peripheral”?

The word “peripheral” that appears in DMA explanations is a collective term for all hardware modules other than the CPU and memory.

All of these are hardware operated by reading and writing to specific registers. DMA automatically shuttles data between a buffer in RAM and these peripheral registers.

What “Without CPU Involvement” Really Means

Let’s look at what it means for the CPU to be “involved,” at the hardware level.

Inside a microcontroller, the CPU, DMA, RAM, and peripherals are all connected by the AHB bus (Advanced High-performance Bus) — a shared highway.

Both the CPU and DMA are bus masters connected to the same bus. Either can access RAM or peripherals.

“Without CPU involvement” means “instead of the CPU occupying the bus to repeat LDR/STR, the DMA uses the bus to move data.” The CPU doesn’t need to use the bus during that time — it can focus on computation and control logic.

DMA’s Three Elements

Each also has an address-increment setting:

⚡ Why Do We Need DMA?

Interrupts Still Leave the CPU Occupied

In interrupt-based UART transmission (Episodes 8–9), every time UART finishes one byte an interrupt fires, and the CPU writes the next byte to the DR register — over and over.

Byte 1 done → interrupt → CPU writes byte 2 to DR
Byte 2 done → interrupt → CPU writes byte 3 to DR
    …… (repeats for every byte)

Sending 100 bytes triggers 100 interrupts, and the CPU runs an ISR each time.

⚠️ 画像が見つかりません: without_dma.png

With DMA, Only One Interrupt — at Completion

CPU tells DMA: "send N bytes from this buffer to UART DR"
  ↓
DMA autonomously transfers one byte at a time (CPU can do other work)
  ↓
Transfer complete → DMA fires one interrupt
  ↓
CPU "prepares the next data" — that's all

⚠️ 画像が見つかりません: with_dma.png

🏗 STM32’s DMA Architecture

DMA1 and DMA2

The STM32F401RE has DMA1 (8 streams) and DMA2 (8 streams).

• DMA1: Handles APB1 peripherals (USART2, I2C1, SPI2, etc.)
• DMA2: Handles APB2 peripherals (USART1, SPI1, ADC1, etc.) + memory-to-memory transfers

Streams and Channels

Each DMA has 8 streams (Stream0–7); each stream selects one of 8 channels (Channel0–7). The channel determines which peripheral’s DMA request is accepted.

DMA Transfer Modes

🛠 DMA-ifying UART TX (Practice)

CubeMX Configuration

1. USART2 → Mode: Asynchronous (Baud: 115200)
2. DMA Settings tab → Add → USART2_TX
   • Direction: Memory To Peripheral
   • Mode: Normal
   • Increment: Memory ✅ / Peripheral ❌
3. NVIC Settings → DMA1 stream6 global interrupt → Enable ✅

⚠️ 画像が見つかりません: cubemx_dma.png

Generated Code

Key parts of the initialization code CubeMX generates:

/* Excerpt from MX_DMA_Init() in main.c */
hdma_usart2_tx.Instance                 = DMA1_Stream6;
hdma_usart2_tx.Init.Channel             = DMA_CHANNEL_4;
hdma_usart2_tx.Init.Direction           = DMA_MEMORY_TO_PERIPH;
hdma_usart2_tx.Init.PeriphInc           = DMA_PINC_DISABLE;   /* DR fixed */
hdma_usart2_tx.Init.MemInc              = DMA_MINC_ENABLE;    /* advance through buffer */
hdma_usart2_tx.Init.PeriphDataAlignment = DMA_PDATAALIGN_BYTE;
hdma_usart2_tx.Init.MemDataAlignment    = DMA_MDATAALIGN_BYTE;
hdma_usart2_tx.Init.Mode                = DMA_NORMAL;
hdma_usart2_tx.Init.Priority            = DMA_PRIORITY_LOW;

Implementation: DMA Transmission

/* Global buffer (must remain in RAM throughout the DMA transfer) */
static uint8_t g_tx_buf[64];
volatile bool g_tx_busy = false;   /* <stdbool.h> */

/* Start a DMA transmission */
void uart_send_dma(const char *str)
{
    uint16_t len = strlen(str);
    if (len > sizeof(g_tx_buf)) len = sizeof(g_tx_buf);

    /* Wait if a transfer is already in progress (or handle as error) */
    while (g_tx_busy);   /* ← polling — see note below */

    memcpy(g_tx_buf, str, len);
    g_tx_busy = true;

    HAL_UART_Transmit_DMA(&huart2, g_tx_buf, len);
    /* ← CPU returns here immediately; DMA handles the rest */
}

/* Transfer-complete callback (called from the DMA interrupt) */
void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart)
{
    if (huart->Instance == USART2)
    {
        g_tx_busy = false;   /* allow the next transmission */
    }
}

/* while(1) in main */
while (1)
{
    char msg[32];
    snprintf(msg, sizeof(msg), "tick=%lu\r\n", g_tim2_tick);

    uart_send_dma(msg);   /* CPU returns immediately */

    /* CPU is free to do other work */
    HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5);
    HAL_Delay(500);
}

/* Non-blocking design */
if (g_tx_busy) return HAL_BUSY;   /* let the caller decide */

Verification: Measuring with DWT CYCCNT

/* Measure CPU time from DMA launch to callback */
uint32_t t_start = DWT->CYCCNT;
HAL_UART_Transmit_DMA(&huart2, g_tx_buf, len);
uint32_t t_launch = DWT->CYCCNT - t_start;
/* t_launch ≈ a few tens to a few hundred cycles (just the "launch" cost) */

/* For comparison: blocking version */
t_start = DWT->CYCCNT;
HAL_UART_Transmit(&huart2, g_tx_buf, len, HAL_MAX_DELAY);
uint32_t t_blocking = DWT->CYCCNT - t_start;
/* t_blocking ≈ bytes × 86.8µs × 84 cycles/µs (CPU occupied the whole time) */

Comparison example for a 64-byte transmission:

The blocking CPU occupancy scales linearly with the byte count:

With DMA, this cost collapses to a fixed \approx 200\,\text{cycles} launch overhead — independent of N_{\text{bytes}} .

📊 Throughput and Latency

Let’s clarify why DMA feels “faster.”

Throughput (Transfer Volume per Unit Time)

Whether or not you use DMA, the physical transfer speed of UART does not change. 115200 bps is 115200 bps.

What DMA improves is not throughput — it’s the time the CPU has available for other work.

Latency (Responsiveness)

With DMA, the “waiting time” for a UART transmission is nearly zero from the CPU’s perspective.

【Blocking】
CPU locked to transmission ─────────────────────────── freed
               ↑TX start                             ↑TX complete

【DMA】
CPU issues start ─ freed
              ↑                DMA transfer complete
                               ↑callback via interrupt

This difference is the “latency improvement.” The CPU can move on to the next task immediately.

🔀 Bus Contention

AHB Bus Matrix

The STM32F4 uses an AHB (Advanced High-performance Bus) Matrix structure. The CPU and DMA exist as independent bus masters and share the same bus.

When Contention Occurs

If the CPU and DMA try to access the same memory simultaneously, one of them must wait.

CPU: about to read g_tx_buf (in SRAM)
DMA: currently reading data from g_tx_buf (in SRAM)
  → Bus arbitration fires → one party waits 1 cycle

Bus arbitration is the hardware mechanism that referees competing simultaneous access attempts — the traffic controller of the bus. This situation is called bus contention.

⚠️ Common Pitfalls

Pitfall 1: Overwriting the Buffer Before the Transfer Completes

/* ❌ Overwriting the buffer while DMA is still reading it */
uint8_t tx_buf[64];

HAL_UART_Transmit_DMA(&huart2, tx_buf, 32);
/* While DMA is still reading tx_buf… */
memset(tx_buf, 0, 64);   /* ← Corrupts the buffer! */

DMA is still reading the old buffer, but the CPU overwrites it. The transmitted data is corrupted.

/* ✅ Confirm completion via callback before the next operation */
volatile uint8_t g_tx_done = 1;

void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart)
{
    g_tx_done = 1;
}

/* Check the done flag before transmitting */
while (!g_tx_done);   /* wait for the previous transfer to finish */
g_tx_done = 0;
memcpy(tx_buf, new_data, len);
HAL_UART_Transmit_DMA(&huart2, tx_buf, len);

Pitfall 2: Using a Local (Stack) Variable as a DMA Buffer

/* ❌ Using a stack-local variable as a DMA buffer */
void send_message(void)
{
    char buf[32] = "Hello DMA!\r\n";
    HAL_UART_Transmit_DMA(&huart2, (uint8_t*)buf, 12);
    /* ← When the function returns, the stack is freed.
          DMA is still reading that "former stack" area! */
}

DMA buffers must be global variables or static local variables.

/* ✅ static keeps it alive beyond the function scope */
void send_message(void)
{
    static char buf[32];
    snprintf(buf, sizeof(buf), "Hello DMA!\r\n");
    HAL_UART_Transmit_DMA(&huart2, (uint8_t*)buf, 12);
}

Pitfall 3: Misusing volatile on DMA Buffers

You might want to mark a DMA-written buffer (e.g. a receive buffer) as volatile, but when using HAL you need to be careful.

/* Tricky example: volatile uint8_t as a DMA buffer */
volatile uint8_t rx_buf[64];

/* Passing a volatile pointer to HAL_UART_Receive_DMA() may
   produce a compiler warning (HAL doesn't expect volatile) */

Because the HAL DMA driver manages cache internally, the safer approach on the application side is to omit volatile and instead control access timing via callbacks.

Pitfall 4: D-Cache and Coherency Problems

This problem applies to any MCU that has a D-Cache (data cache) — not just the STM32F7/H7. MCUs based on Cortex-M7 or higher, such as NXP i.MX RT, Renesas RZ, and the high-performance lines from various vendors, are all equally affected.

Because DMA accesses RAM directly without going through the cache, the CPU’s cached view of memory and the actual RAM contents can go out of sync (coherency problem). The STM32F401 has no D-Cache, so this never occurs in this series — but any MCU with D-Cache requires explicit handling when using DMA.

RX Direction (DMA → RAM → CPU) Failure

DMA writes received data to rx_buf in RAM (bypasses cache)
   ↓
CPU tries to read rx_buf
   → Cache still holds stale data (zeros or data from previous transfer)
   → CPU reads from cache, not RAM ← corrupted

Symptom: Buffer reads as all zeros, or unchanged from the previous transfer. Inserting a printf “fixes” it (the memory access flushes the cache, making it non-reproducible).

TX Direction (CPU → RAM → DMA) Failure

CPU writes new data to tx_buf
   → Write-back cache: data is in cache but not yet written to RAM
   ↓
DMA reads tx_buf directly from RAM → sends stale data ← corrupted

Symptom: Transmitted data is the same as the previous transfer, or is garbage.

Fix: SCB_CleanDCache / SCB_InvalidateDCache

/* ---- After RX: invalidate cache so CPU reads fresh data from RAM ---- */
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)
{
    SCB_InvalidateDCache_by_Addr((uint32_t*)rx_buf, sizeof(rx_buf));
    process_received_data(rx_buf);   /* data is now up to date */
}

/* ---- Before TX: flush cache to RAM so DMA reads the latest data ---- */
void uart_send_dma(uint8_t *data, uint16_t len)
{
    memcpy(tx_buf, data, len);
    SCB_CleanDCache_by_Addr((uint32_t*)tx_buf, sizeof(tx_buf));
    HAL_UART_Transmit_DMA(&huart2, tx_buf, len);   /* DMA now reads fresh data */
}

/* DMA buffers must be 32-byte aligned */
__attribute__((aligned(32))) uint8_t rx_buf[64];
__attribute__((aligned(32))) uint8_t tx_buf[64];

Summary

What we learned in this episode:

Next up is “Linker Scripts and Map Files (Looking Under the Hood).” We’ll learn where .text, .data, and .bss are placed, and how to track RAM consumption with a map file.

Next Episode

FAQ

Q. Does using DMA make UART transmission “faster”?

The physical transfer speed (bps) does not change. What improves is the time the CPU has available for other processing. The time previously locked up in transmission approaches zero, so the system’s overall responsiveness improves.

Q. Can I call HAL_UART_Transmit_DMA() back-to-back?

Calling it before the previous transfer completes returns an error (HAL_BUSY). The correct pattern is to set a flag in HAL_UART_TxCpltCallback() and check for completion before each new transmission.

Q. When do you use Circular mode?

When you need to stream data continuously — ADC sampling, audio output, and similar cases. In Circular mode, when the transfer completes, DMA automatically wraps back to the start, and the HalfCpltCallback (half complete) and CpltCallback (full complete) enable double-buffered processing.

Q. Can DMA be used with peripherals other than UART?

Yes. Almost all peripherals support DMA — SPI, I2C, ADC, DAC, timers, and more. In particular, running SPI (high speed) and ADC (high-frequency sampling) without DMA is impractical in most real applications.

Related Articles

• Episode 9: Interrupt Design Anti-Patterns
• Episode 8: Understanding Interrupts — Vector Table, NVIC, and the Danger
• Episode 7: The World of Time — Knowing the Weight of a Single Cycle
• Full 13-Part Series: The Embedded World Beyond Pointers