STM32U575/585 GPDMA使用指南：从CubeMX配置到链表实战

很多从 STM32F1/F4 跳到 STM32U575/585 的工程师，第一次打开 CubeMX 找 DMA 配置时都会愣一下：外设列表里没有经典的 DMA1/DMA2，而是 GPDMA。如果你去翻 RM0456，会看到它的全称是 General-Purpose Direct Memory Access，中文一般叫通用 DMA 控制器，日常沟通里大家都简写成 GPDM。这篇文章就围绕 STM32U575-585 微控制器的 GPDM 怎么用展开，聊聊它和老系列 DMA 在使用习惯上的差异、从 CubeMX 到 HAL 的落地步骤、多块传输与链表操作，以及我在实际调试中踩到过的一些坑。适合正在用 U5 做低功耗数据采集、传感器后台搬运、UART/SPI 大块数据收发的人参考。

1. 把 GPDM 和传统 DMA 的差异先摊开

1.1 GPDM 不是“另一个 DMA 编号”，而是一套新的控制器框架

STM32F1/F4 时代的 DMA，核心概念是“DMA 通道”和“外设请求编号”。比如 F1 上 USART1_TX 固定挂在 DMA1 的某个通道上，软件要做的就是把外设请求对号入座。到了 STM32U575-585，GPDMA 把这种固定映射关系打破了。

U5 的 GPDMA 虽然也叫 DMA，但它的设计思路更接近“一个可编程的搬运引擎”。每个 DMA 通道不绑定某类外设，而是通过请求映射把任意可触发 DMA 的外设事件导向指定通道。也就是说，你可以把 ADC1 的转换完成事件接到通道 0，也可以接到通道 3，只要保证没有两个通道同时抢同一个外设请求即可。

这个变化带来的第一个影响是：寄存器结构完全不同。打开 stm32u5x 的头文件，你会发现它没有旧版那种 DMA_TypeDef，而是 GPDMA_TypeDef。里面的寄存器围绕“Block Transfer”和“Linked-List”来组织。换句话说，GPDMA 不仅仅是搬运数据，它还能按预先排好的描述符链自动切换搬运任务，CPU 只要在链尾等待完成中断。

提示：很多人初期看不懂 GPDMA 代码，不是因为 C 语言水平不够，而是脑子里还残留着老 DMA 的“通道-外设固定映射”模型。先接受“请求映射 + 链表描述符”这两个新概念，后面一切都顺了。

1.2 相对 STM32F1/F4 的 DMA，代码层面要改哪些习惯

老项目往 U5 移植时，DMA 驱动这块基本不能直接抄。我从 F407 项目迁移到 U575 后，整理了一张自己用的对照表：

这张表不是严格的性能对比，而是为了提醒你：代码结构要变，排查问题的思路也要变。如果之前习惯“反正 DMA 通道能对上就行”，到了 U5 必须多看一层请求映射表。哪些外设请求能触发哪些 GPDMA 通道，这些信息在 RM0456 的外设请求映射章节里都有，用 CubeMX 配置时也会自动生成。

2. 从 CubeMX 到 HAL：第一次让 GPDM 跑起来

2.1 CubeMX 里找到 GPDMA 并绑定外设请求

我用 STM32CubeMX 配置 U575 的 USART1 DMA 接收，操作路径大致如下：

1. 在 Pinout 视图里先启用 USART1，并配置好异步模式、波特率等参数。
2. 选中 USART1，切到 DMA Settings 标签页。
3. 点击 Add，通道列表里会出现 GPDMA1 的通道选项，请求类型选择 USART1_RX。
4. 配置数据宽度、地址自增、Normal 还是 Circular 模式。
5. 生成代码后，CubeMX 会自动生成一个类似 MX_GPDMA1_Init 的函数，并建立 UART 和 GPDMA 的连接关系。

不同版本的 CubeMX 界面措辞会变，有的版本在 DMA Settings 里写 GPDMA1，有的写 DMA1_Channel0，但本质都是同一个东西。关键是请求映射不要选错，如果 USART1_RX 的请求被指派给了某个正在被其他外设使用的通道，就会出现两个外设抢通道的诡异现象。

2.2 HAL_GPDMA 初始化和启动代码怎么读

生成后的代码里大概率会看到这样的结构：

GPDMA_HandleTypeDef hgpdma; DMA_NodeTypeDef Node_GPDMA1_USART1_RX;

GPDMA_HandleTypeDef是 GPDMA 通道句柄，DMA_NodeTypeDef是链表节点描述符。初学者容易混淆：句柄代表一个 DMA 通道当前正在执行的搬运任务，节点描述符则代表“这个任务里更小单位的搬运操作”。即使不用链表，HAL 也可能用节点结构来描述单次搬运，因为 GPDMA 内部把 Block Transfer 作为基本调度单位。

UART 这类外设使用 DMA 时，HAL 驱动会替你做大部分封装。比如调用HAL_UART_Receive_DMA(&huart1, rx_buf, RX_BUF_LEN)后，HAL 内部会把huart1.hdmarx指向的 GPDMA 通道启动起来，并注册完成回调。

如果你直接操作 GPDMA，可以这样启动一次内存到内存的搬运：

if (HAL_GPDMA_Start_IT(&hgpdma, (uint32_t)src_buffer, (uint32_t)dst_buffer, transfer_length) != HAL_OK) { Error_Handler(); }

启动后，GPDMA 通道中断服务函数里要调用 HAL 的统一入口：

void GPDMA1_Channel0_IRQHandler(void) { HAL_GPDMA_IRQHandler(&hgpdma); }

完成回调的名字根据你用的 HAL 版本略有差异，常见的是：

void HAL_GPDMA_XferCpltCallback(GPDMA_HandleTypeDef *hgpdma) { // 对本次搬运结果进行处理 }

注意：如果数据通路是经过 UART 驱动的，完成后触发的是HAL_UART_RxCpltCallback，而不是HAL_GPDMA_XferCpltCallback。两种回调的触发路径不同，不要在自己工程里两个都写然后发现一个没执行。

2.3 一个可以直接抄的 UART DMA 收发示例

下面这套是我在 U575 开发板上验证过的简化写法，全局只维护一个接收缓冲，循环接收：

#define RX_BUF_LEN 256 uint8_t rx_buf[RX_BUF_LEN]; volatile uint8_t rx_cplt_flag = 0; void Start_UART_DMA_RX(void) { HAL_UART_Receive_DMA(&huart1, rx_buf, RX_BUF_LEN); } void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart->Instance == USART1) { rx_cplt_flag = 1; // 尽量不在中断里做耗时处理，只置标志 } }

主循环里检测到rx_cplt_flag后，把数据搬走，然后再次调用HAL_UART_Receive_DMA重新启动。这里有个容易踩的细节：HAL_UART_Receive_DMA的第三个参数是字节数，而不是 GPDMA 数据宽度对应的“搬运次数”。如果你的 GPDMA 配置成了半字宽度，别直接把RX_BUF_LEN / 2传进去，除非你清楚 HAL 内部会做换算。

3. 多块传输、Block/Repeat 与 Linked-List：用 GPDM 处理非规则数据

3.1 先理解 GPDMA 的数据组织层次

GPDMA 之所以叫 General Purpose，一个很重要的原因是它支持多级传输描述。从软件角度看，GPDMA 的数据搬运可以拆成三个层级：

• 传输（Transfer）：整个 DMA 任务，比如从外设连续搬 1KB 数据到内存。
• 块（Block）：传输任务内部的基本单元，一个传输可以由多个块组成。
• 链表节点（Node）：用来描述一个传输的起始地址、目标地址、块大小、下一节点指针等。

举个例子：你要通过 UART 发送“帧头 + 负载 + CRC”，传统做法是先等 CPU 把三个部分拷贝到同一个连续 buffer，再启动一次 UART DMA。用 GPDMA 链表的话，你可以在内存里定义三个节点，分别指向帧头数组、负载数组、CRC 数组，然后让 UART 的 DMA 请求按链表顺序依次发送三段数据。CPU 只要初始化一次链表，后续发送事件完全由 GPDMA 自动触发。

3.2 Linked-List 节点配置与注意事项

不同版本的 STM32CubeU5 固件包提供的链表接口略有出入，但核心配置参数是一致的。我在工程里一般这样组织节点：

DMA_NodeTypeDef Node_Header; DMA_NodeTypeDef Node_Payload; DMA_NodeTypeDef Node_CRC; void Setup_UART_TX_Linked_List(void) { // 第一个节点：搬运帧头 HAL_GPDMA_LinkedList_Configure(&Node_Header, DMA_NODE_CFG_BLOCK_SINGLE, (uint32_t)header_buf, (uint32_t)&huart1.Instance->TDR, HEADER_LEN, DMA_NODE_CFG_SRC_INCR_ENABLE, DMA_NODE_CFG_DST_INCR_DISABLE); // 第二个节点：搬运负载 HAL_GPDMA_LinkedList_Configure(&Node_Payload, DMA_NODE_CFG_BLOCK_SINGLE, (uint32_t)payload_buf, (uint32_t)&huart1.Instance->TDR, PAYLOAD_LEN, DMA_NODE_CFG_SRC_INCR_ENABLE, DMA_NODE_CFG_DST_INCR_DISABLE); // 第三个节点：搬运 CRC HAL_GPDMA_LinkedList_Configure(&Node_CRC, DMA_NODE_CFG_BLOCK_SINGLE, (uint32_t)crc_buf, (uint32_t)&huart1.Instance->TDR, CRC_LEN, DMA_NODE_CFG_SRC_INCR_ENABLE, DMA_NODE_CFG_DST_INCR_DISABLE); // 串成链表 HAL_GPDMA_LinkedList_Append(&Node_Header, &Node_Payload, NULL); HAL_GPDMA_LinkedList_Append(&Node_Payload, &Node_CRC, NULL); // 后续把 Node_Header 作为首个节点启动即可 }

上面对节点配置函数做了理想化处理，实际函数名以你 CubeMX 生成代码里 stm32u5xx_hal_gpdma.h 为准，但参数含义类似。链表一旦启动，GPDMA 会按节点的 next 指针一个个执行，直到遇到 NULL 或链表末尾。

这里有几个非常容易出问题的点，我全部踩过：

1. 节点描述符本身要放在普通可读写的 RAM 里，不能放在 Flash 常量区，否则 GPDMA 读取链表时可能产生总线错误。
2. 各节点描述符的地址尽量 32 位对齐，不要用#pragma pack(1)去压缩结构体尺寸。
3. 如果开了 D-Cache，必须在启动链表前对节点描述符所在内存区域做 clean，搬运完成后对数据 buffer 做 invalidate，否则可能出现“数据明明是新的，读出来却是旧的”这种灵异问题。

3.3 低功耗场景为什么要依赖 GPDMA 的链式搬运

STM32U575-585 主打低功耗，GPDMA 有一个很关键的能力是可以在 CPU 保持低功耗状态时，继续等待外设请求并搬运数据。再配合 LPBAM（Low-Power Background Autonomous Mode）类机制，可以实现：定时器唤醒 ADC 采样 -> GPDMA 把采样结果搬到内存 -> 搬运完成后触发一次 LPUART 发送。整个过程 CPU 不参与，功耗能压得很低。

链路配置的核心还是链表。因为 CPU 睡眠后无法再逐次配置 DMA，必须提前把所有搬运动作编排成链表描述符，让 GPDMA 按计划自动执行。这也是我在实际项目里愿意花时间研究 GPDMA 链表的原因：它省的不是几条代码，而是整条低功耗数据通路的设计复杂度。

4. U5 平台特有坑：SRAM 分区、时钟门控和中断回调

4.1 缓冲区地址被安排在不可被 DMA 访问的 SRAM 区

STM32U575-585 内部有多个 SRAM 区域，不同区域的访问权限和功耗特性不一样。GPDMA 虽然能访问大部分片上 RAM，但并不是说随便定义一个全局数组就一定能被它搬。工程里最容易出现的问题是：把 DMA buffer 定义在了备份 SRAM，但没有提前使能备份域供电和时钟，结果 GPDMA 启动后一直拿不到数据，甚至直接 HardFault。

解决思路很朴素：定义 DMA buffer 前，先查一遍 RM0456 里 GPDMA 可访问地址范围，确认 buffer 所在地址在这张表里。养成习惯后，这类问题基本可以一次避开。

另一个非常 U5 特色的问题是 TrustZone。如果你在工程里启用了 TrustZone，GPDMA 通道本身也有安全/非安全属性。非安全代码操作非安全 GPDMA 通道，去访问一个被标记为安全的内存区域，会被总线过滤器拦下来。这个问题在普通 F4 上不存在，从老项目迁移时特别容易忽略。

4.2 GPDMA 的中断回调里千万不能做的事

GPDMA 完成中断虽然不像定时器中断那么频繁，但在高吞吐场景下也可能每几十微秒触发一次。如果你在回调里做这些事，基本都会出问题：

• 调用HAL_Delay()：SysTick 本身是基于中断的，在 DMA 中断里调用它，优先级配得不好时直接死等。
• 做耗时的内存拷贝：尤其不要在同一缓冲区上来回 memcpy，会把中断占死。
• 不做标志清理就重新启动 DMA：循环模式下，停止和重新启动之间有严格的时序要求。
• 直接打印调试信息：如果调试串口也用 DMA，可能会互相等。

我自己的习惯是：真正完成回调里只置位一个 volatile 标志，最多把收到的长度记录一下，所有业务逻辑放到主循环或 RTOS 任务里处理。这样调试起来清爽很多。

4.3 关了 GPDMA 时钟导致 DMA 不工作的排查顺序

有一次我把 U575 从低功耗模式唤醒后，GPDMA 死活不工作。最后发现是在进入低功耗前，为了省电把 GPDMA1 的时钟关了，唤醒后没有重新打开。这类问题排查时可以按下面顺序走：

1. 检查RCC->AHBxENR里 GPDMA1 时钟是否使能。
2. 检查外设本身的 DMA 请求是否开启，比如 UART 要置位某些控制位才允许 DMA 请求。
3. 用调试器查看 GPDMA 通道的中断状态寄存器，确认是没有请求，还是请求到了但搬运出错。
4. 检查是否还有旧的传输在挂起，导致新的HAL_GPDMA_Start返回 HAL_BUSY。

多数情况下，“DMA 不动”并不是 DMA 配置错了，而是它所在的时钟域或外设请求源没准备好。

5. 调试 GPDM 的实战方法：从中断标志到总线错误

5.1 用 CPU 暂停时读 GPDMA 状态寄存器定位卡点

遇到 GPDMA 不搬运时，先把 CPU 停在启动 DMA 之后、等待完成之前的位置，然后打开调试器的外设寄存器窗口，找到 GPDMA1 对应通道的状态寄存器。重点看三类标志：

• 传输完成标志：如果已经置位，说明搬运实际完成了，只是中断没进来。
• 传输错误标志：如果置位，大概率是地址访问非法、节点描述符读取失败、或安全属性不匹配。
• 请求挂起状态：如果一直显示等待外设请求，说明外设端没有产生 DMA 请求。

判断到具体是哪一类，再回到配置去查，比瞎改有效得多。

5.2 用 GPIO 翻转法：给每一次搬运完成打时间戳

在没有逻辑分析仪的项目里，我喜欢用 GPIO 翻转来确认搬运节奏。在 GPDMA 完成回调里加一句：

HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5);

用示波器或万用表看这个引脚的翻转频率，就能判断 DMA 中断是否按预期触发。如果用的是中断方式，可以用两个不同引脚分别表示“进入中断”和“真正处理完毕”，从而判断中断里耗了多少时间。

这个方法看起来土，但在现场调试时非常管用。我遇到过一种情况：回调确实执行了，但处理逻辑太长，导致下一次 DMA 完成中断被延后，最终表现为数据丢帧。用 GPIO 翻转一眼就能看出来。

5.3 常见错误码和怎么下手

用 STM32CubeU5 的 HAL 库时，函数返回值或回调参数里会暴露一些错误状态。我整理了项目里最常见的几种：

如果项目里既用了HAL_UART_Receive_DMA，又直接操作了 GPDMA 句柄，特别容易踩 HAL_BUSY。因为 UART 驱动会立刻启动 GPDMA，你再去启动同一个通道肯定失败。这种问题根因不是代码顺序，而是职责边界没有划清：要么让 HAL 外设驱动全权管理 GPDMA，要么完全用 GPDMA 裸接口。

我在实际项目里最后形成了一套固定套路：普通 UART 收发全部走HAL_UART_Receive_DMA/HAL_UART_Transmit_DMA，只有多块拼接、低功耗后台搬运这种复杂流程才直接操作 GPDMA 链表。这样既减少重复代码，也把最容易出错的底层细节限制在一个独立模块里。后期排查问题，只需要先定位是“外设 DMA 通路”还是“GPDMA 链表通路”，思路清晰很多。