How do you debug DMA transfers that appear to silently fail?

DMA failures are notoriously difficult to debug because they often produce no visible error — data simply does not arrive, arrives corrupted, or the system hangs without a HardFault. A systematic approach is essential.

Step 1 — Verify the DMA channel is actually running. Read the DMA stream/channel enable bit (EN in CR) — some configurations clear EN automatically on error. Check the DMA error flags: Transfer Error (TEIF), FIFO Error (FEIF on DMA2), and Direct Mode Error (DMEIF). These flags are often overlooked because the HAL error callbacks are not always connected. Read the NDTR register — if it equals the initial count, no transfers have occurred. If it is decrementing, transfers are happening but data may be going to the wrong place.

Step 2 — Check addresses and alignment. Verify the peripheral address register points to the correct data register (e.g., &ADC1->DR, not &ADC1->SR). Verify the memory address points to a valid, writable RAM region — a common bug is pointing to flash (read-only) or to a stack variable that has gone out of scope. Check alignment: a word-width DMA transfer to an address not aligned to 4 bytes causes a Transfer Error on most STM32 families. On Cortex-M7, also check that the buffer is not in a cached region without proper cache maintenance.

Step 3 — Check the peripheral request connection. On STM32, each DMA channel/stream is hard-wired to specific peripheral request signals (e.g., DMA1 Channel 1 is ADC1 on STM32F1; DMA2 Stream 0 with Channel 0 is ADC1 on STM32F4). Using the wrong DMA channel for a peripheral means the DMA never receives a transfer request, so it sits idle with EN set and NDTR unchanged. Always verify the channel/stream/request mapping against the reference manual's DMA request mapping table.