How Do You Configure STM32U5 GPDMA Linked-List DMA Transfers?

Detailed Explanation

STM32U5 replaces the DMA architecture used on STM32F4, G4, and H7 with GPDMA (General Purpose DMA), a controller built around linked lists rather than the stream/channel model or DMAMUX request routing those families use. See STM32 HAL DMA configuration for how classic DMA works; this page covers what's different on GPDMA and why a design migrating from an L4 or F4-based product should budget real time for it, a gap already flagged in the STM32 family selection guide's comparison table.

On classic STM32 DMA, one HAL_DMA_Init() call configures a single transfer descriptor: one source, one destination, one mode (normal or circular), one data width. Chaining a sequence of different transfers means the CPU has to reconfigure and restart the DMA in an interrupt callback after each one completes. GPDMA removes that CPU round-trip: a channel can be handed a chain of transfer descriptors, called nodes, stored as a linked list in SRAM, and the hardware loads each node's configuration automatically as soon as the previous one finishes.

The Node and Queue Model

Each GPDMA node holds a complete transfer descriptor: source address, destination address, data width, transfer count, and the address of the next node in the chain. When a channel completes the transfer described by its current node, it reads the next node's address directly from the current node's linked-list pointer and continues without CPU intervention or an interrupt firing in between. A chain can end (the last node has no next-node pointer, so the channel stops) or loop back to its first node to run indefinitely.

This makes GPDMA well suited to scenarios that would otherwise need constant reconfiguration on classic DMA: alternating between two peripherals on a fixed schedule, applying a different data width or address-increment pattern partway through a transfer, or streaming a repeating sequence of register writes to a peripheral without CPU wake-ups between each one.

Configuring GPDMA in CubeMX

CubeMX exposes GPDMA configuration through the same peripheral DMA Settings tab used for classic DMA, plus a dedicated linked-list queue builder for cases that need more than a single node:

1. In the peripheral's DMA Settings tab, add a GPDMA request as usual. For a simple one-shot or circular transfer, this alone is enough. CubeMX generates a single-node configuration and the familiar HAL_UART_Transmit_DMA()-style call still works.
2. For a multi-node chain, use CubeMX's linked-list queue editor to define each node's source, destination, and transfer parameters, and the order they execute in.
3. CubeMX generates the corresponding HAL_DMAEx_List_* calls: HAL_DMAEx_List_Init() to prepare the queue structure, HAL_DMAEx_List_BuildNode() for each node, HAL_DMAEx_List_InsertNode() to add nodes to the queue in order, and HAL_DMAEx_List_SetCircularMode() if the chain should loop rather than stop after the last node.

// Simplified structure of a generated linked-list queue setup
DMA_NodeConfTypeDef node_config;
DMA_NodeTypeDef node1, node2;
DMA_QListTypeDef transfer_queue;

// Build each node's transfer descriptor
HAL_DMAEx_List_BuildNode(&node_config, &node1);
HAL_DMAEx_List_BuildNode(&node_config2, &node2);

// Assemble the queue in execution order
HAL_DMAEx_List_InsertNode(&transfer_queue, NULL, &node1);
HAL_DMAEx_List_InsertNode(&transfer_queue, &node1, &node2);

// Attach the queue to the channel and start it
HAL_DMAEx_List_LinkQ(&handle_gpdma, &transfer_queue);
HAL_DMAEx_List_Start(&handle_gpdma);

The exact generated code depends on the queue structure chosen in CubeMX; the pattern above is the shape of it, not a literal drop-in. For the underlying GPDMA register set (channel transfer registers, the linked-list address register, and per-channel request routing), see the GPDMA chapter of the STM32U5 reference manual.

GPDMA1 vs LPDMA1

STM32U5 has two separate DMA controllers with different capabilities:

• GPDMA1 is the general-purpose controller described above, with linked-list support, available to most peripherals and both memory-to-memory and memory-to-peripheral transfers.
• LPDMA1 is a smaller, simpler controller intended to keep a limited set of low-power peripherals (such as LPUART1) transferring data while the MCU is in Stop mode, when GPDMA1 itself is not clocked. LPDMA1 supports only the classic normal and circular transfer modes, not linked lists, and is only connected to a limited peripheral set. A design that needs DMA to continue operating in Stop mode must route that specific transfer through LPDMA1, not GPDMA1.

Design Considerations

• Don't reach for the linked-list API for a simple transfer. If a peripheral only needs one fixed configuration (a normal one-shot transfer or a circular streaming buffer), CubeMX's single-node GPDMA setup and the familiar peripheral-level _DMA() HAL calls are simpler and sufficient. Reserve linked-list queues for sequences that genuinely need to chain multiple distinct transfer configurations.
• Route Stop-mode-active transfers through LPDMA1, not GPDMA1. GPDMA1 is not clocked during Stop mode; only LPDMA1 and its limited peripheral set can keep transferring data while the rest of the MCU is asleep. Confirm during low-power mode selection which specific peripherals a product needs active in Stop mode, since that determines whether LPDMA1's simpler transfer model is sufficient.
• Budget real migration time when porting a DMA-heavy design from L4, F4, or H7. The node/queue programming model is a genuinely different way of thinking about DMA configuration, not a renamed API on top of the same concepts, and code written against classic HAL_DMA_Init() semantics does not port directly.
• STM32U5 GPDMA and LPDMA firmware: getting a linked-list transfer chain, or the GPDMA/LPDMA split for low-power designs, right the first time is exactly the kind of platform-specific firmware work Zeus Design's embedded team handles for production STM32U5 products.

Common Mistakes

• Assuming GPDMA's peripheral request routing works identically to DMAMUX on H7/G4/L4 and skipping verification against the U5-specific request mapping, when the underlying request assignments differ by family even though both use flexible per-channel routing.
• Building a linked-list queue without setting circular mode when the transfer is meant to repeat indefinitely, causing the channel to correctly execute the chain once and then stop, which looks like a hang rather than the actual cause (a terminated, non-looping chain).
• Trying to keep a GPDMA1-routed transfer active through Stop mode, when only LPDMA1 and its limited peripheral set remain clocked in that low-power state.
• Treating the linked-list API as a mandatory replacement for the simple single-node case, adding queue-building complexity to a transfer that only ever needed one fixed configuration.