最近两年做低功耗物联网的朋友应该都开始把目光往STM32U5系列上靠了。我第一次拿到STM32U575 的开发板时板子跑分确实漂亮TrustZone 也很唬人但真正让我心里一紧的是打开参考手册看到 DMA 那一章的时候——原来熟悉的 DMA1/DMA2 不见了取而代之的是一个叫 GPDMA、一个叫 LPDMA 的新家伙。说实话第一次接触 GPDMA 我有点懵寄存器不一样了中断回调变了还多了链表描述符这种以前只在高端芯片上见过的概念。把整套架构摸清楚之后我反倒觉得 ST 这步棋走得非常聪明GPDMA 负责常规的高性能搬运LPDMA 负责低功耗模式下的数据保活两条腿走路。这篇应用笔记就围绕 STM32U575-585 的 GPDMA把它的工作原理、配置方法和实际工程里的坑都摊开讲一讲给正在被 U5 的 DMA 搞头疼的朋友一份可以直接抄作业的参考。1. GPDMA到底“新”在哪从老DMA到U5的架构变化1.1 为什么ST要把DMA架构推倒重来STM32F1/F4 时代的老 DMA大家应该都很熟DMA1 有 7 个通道DMA2 有 5 个通道每个通道和外设的映射关系基本是写死的。你用 USART1_TX就只能用 DMA1 的通道 4想换通道不行那是硬件连接。这种固定映射在小工程里没啥问题但一旦外设一多通道分配表就得靠工程师手工拉 Excel 去排非常痛苦。到了 STM32U5 系列ST 直接把这套旧架构推倒重来了。原因也很直白U5 走的是超低功耗 高性能的定位老式 DMA 有几个硬伤解决不了老 DMA 的触发源固定缺乏灵活性面对 TrustZone 带来的安全/非安全总线隔离老架构很难平滑适配。老 DMA 在深度低功耗模式下基本歇菜U5 想实现 Stop 模式下外设依然能搬运数据需要为低功耗场景单独设计一套 DMA。老 DMA 一次只能配置一个传输任务多段不连续内存搬运必须靠 CPU 反复发起 DMA效率很低。所以 U5 上的 DMA 被拆成了两个角色GPDMA 负责系统正常运行时的通用搬运LPDMA 负责低功耗模式下继续工作。这就像一个大公司白天有主力物流车队干重活晚上有夜班小分队保证核心物资不断供。GPDMA 和 LPDMA 虽然都是 DMA但设计目标和寄存器模型并不完全一样后续配置时一定要区分清楚。1.2 GPDMA和LPDMA的分工很多新手拿到 U575 的参考手册看到 GPDMA 和 LPDMA 两个章节第一反应是“选一个用就行”。这里必须敲黑板两个都不是可选替代关系而是分工关系。对比项传统DMAF1/F4GPDMALPDMA定位常规外设搬运高性能常规搬运低功耗模式下的搬运通道数7/5通道通道资源充足支持多请求复用通道数较少够低功耗场景用触发源通道固定映射通过请求复用器灵活映射同样支持请求复用链表描述符不支持原生支持多个传输任务可串接同样支持低功耗模式Stop模式基本不可用深睡眠场景受限可在Stop 2等低功耗模式下保持工作数据传输宽度8/16/32位最高支持64位双字访问8/16/32位为主从这张表能看出来GPDMA 是主力运输队LPDMA 是低功耗值守小分队。实际项目里我通常的做法是系统活跃时的 ADC 采样、串口通信、SPI Flash 读写全部走 GPDMA进入 Stop 2 模式后需要保持工作的外设比如低功耗串口接收唤醒帧、传感器数据周期采集用 LPDMA 接管搬运工作。要特别提醒一句GPDMA 虽然名字里带“Generic”但并不意味着它在所有低功耗模式下都能跑。GPDMA 需要系统时钟在运行进入深度低功耗模式后它一样会停摆。所以千万别拿 GPDMA 去实现 Stop 模式下的数据保活那是 LPDMA 的地盘。2. GPDMA的“路由中枢”请求复用器与数据流配置2.1 请求复用器是什么老 DMA 是硬件固定映射U5 的 GPDMA 则引入了一个类似路由器的模块请求复用器DMAMUX。你不需要再关心“这个外设请求必须落到哪个通道”任何外设的请求都可以通过寄存器配置映射到任意一个 GPDMA 通道上。打个比方老 DMA 通道像写字楼里的固定停车位你的车只能停在那个专属车位别人占了你就没办法GPDMA 的复用器则像停车场调度系统不管车从哪个方向来只要车位空闲调度员就能把它引导过去。这样带来的直接好处是 PCB 和软件设计都灵活得多换外设通道时不再需要去核对那张映射表。实际使用上你在 CubeMX 里给某个外设添加 DMA 通道时图形界面会直接给出可选的 GPDMA 通道和请求源。比如给 USART1 的 RX 配置 GPDMA只需要在配置界面里选择对应的外设请求CubeMX 会自动完成通道分配和复用器配置不需要你手动去翻寄存器找请求号。但如果你用 LL 库或者直接操作寄存器就需要在代码里把请求源编号写到对应的通道请求选择寄存器里这部分就要看清楚参考手册里面的请求映射表了。2.2 外设请求与硬件触发GPDMA 的触发源和传统 DMA 一样分为三类软件触发、外设请求触发、硬件触发。软件触发最简单就是 CPU 发一条指令让 GPDMA 开始搬运典型场景是内存到内存的拷贝。外设请求触发是用的最多的外设 RX 缓冲区有数据了向 GPDMA 发一个请求GPDMA 就开始搬运搬运完一段外设再发请求GPDMA 再搬配合传输完成中断实现全自动的数据流处理。硬件触发这个功能就有点意思了。它把外部事件或定时器事件当做一个“门控信号”GPDMA 要等到门控信号来了才会执行一次传输。简单说外设请求负责告诉 GPDMA“有货要搬”硬件触发负责告诉 GPDMA“现在可以开始搬”。这种双条件机制非常适合固定的采样场景比如用定时器 PWM 波形触发 ADC 采样ADC 转换完成后产生请求GPDMA 把采样结果搬到内存整个过程完全不需要 CPU 干预时序也是硬实时保证的。我在实际项目里用过一个场景用高级定时器输出 PWM 驱动传感器同时在 PWM 的上升沿触发内部 ADC 采样采样结果通过 GPDMA 循环模式持续搬运到内存数组里。这样 CPU 只需要在后台做数据处理采样率能做到很高的稳定性。2.3 数据宽度、方向与突发GPDMA 支持 8 位、16 位、32 位、64 位四种数据宽度。这里要特别注意源和目的的数据宽度可以不一致GPDMA 会自动做位宽转换。比如从 8 位的 UART 数据寄存器读取数据搬运到 32 位的内存缓冲区GPDMA 会把每 4 个字节组合成一个 32 位字写入内存。这种情况下要留意字节序和填充方式否则数据组包错位排查起来很坑。突发传输Burst是 GPDMA 提升带宽的重要特性。突发长度支持 1、4、8 和 16也就是一次突发连续搬 4 个、8 个或 16 个数据单元。突发传输适合源或者目的地址是对齐的场景比如把整块 Flash 数据搬运到 SRAM突发模式能充分利用总线带宽。但如果不是对齐的地址突发传输可能会触发错误这点在协议缓冲区不固定的场景下要特别注意。一个性能优化的心得U5 内核和总线本身支持 64 位访问如果你搬运的数据量大尽量把源地址、目的地址和数据长度都按双字8字节对齐然后在 CubeMX 里把数据宽度选成 64 位、突发长度设为 4 或 8。实测下来在大量数据拷贝场景下相比 32 位非突发配置带宽能提升接近一倍。不过小数据量传输就别折腾了突发模式带来的配置开销可能比数据传输本身还大反而得不偿失。3. 链表描述符LLI一个描述符串起多个传输任务3.1 链表模式解决了什么问题传统 DMA 每个通道一次只能执行一个传输任务这个任务做完要么停下来等 CPU 重新配置要么依赖循环模式不断重复同一块缓冲区。遇到“三段不连续内存拼成一包数据发出去”这种需求老办法只能先在 RAM 里开一个大 buffer用 CPU 把三段数据 memcpy 到一起再开启一次 DMA 发送。这个过程既浪费 RAM又增加延迟。GPDMA 的链表模式Linked-list Mode就是来解决这个痛点的。它允许你把多个传输任务用链表节点串起来每个节点描述一个独立的传输操作包括源地址、目的地址、传输长度、控制参数以及下一个节点的地址。GPDMA 自动完成第一个任务后会顺着指针跑到下一个节点继续执行全部执行完再触发完成中断。如果你熟悉快递配送这个模式就很好懂普通 DMA 叫“单程出租车”你告诉司机去一个地方到了就结束链表模式是“接力配送单”每个配送站都贴着下一站的地址和货物清单快递员到了一个站照着清单和下一站地址继续跑直到完成整个线路。做协议栈的时候这个功能真的能省掉大量内存拷贝。3.2 LLI描述符的内容与内存摆放一个 LLI 描述符在内存里本质上就是一组结构体字段核心内容包含源地址SRC_ADD本次传输的起始源地址。目的地址DST_ADD本次传输的目的起始地址。传输长度TRANSF_LEN本次传输的数据量。控制字CTRL数据宽度、突发长度、传输模式等配置。下一个LLI指针NEXT_LLI指向下一个描述符的地址如果是最后一个节点可以配置为 0 表示结束。描述符本身需要放在 RAM 中因为 GPDMA 在执行过程中要读它。这里有个容易踩的坑如果没有使能 Cache或者 Cache 策略配置不当描述符更新后 GPDMA 可能读到旧数据导致链表乱跳甚至卡死。还有一个关键点是内存对齐。GPDMA 要求 LLI 描述符的地址按照其读取宽度对齐通常建议至少 4 字节对齐最好 8 字节对齐。我习惯在代码里用__ALIGNED(8)来声明描述符数组防止编译器把它分配到一个诡异的位置。3.3 实操三段内存拼接发送我举个实际例子。设备上报数据时数据包是“包头 负载 CRC”三段分别存放在三个不同的缓冲区里。传统做法是先把它们拷贝到一个连续发送缓冲区再启动 DMA 发送。有了链表模式我直接配置三个 LLI 节点依次指向包头、负载和 CRC 缓冲区然后启动 GPDMA它就会自动把三段数据连续发出去。用 LL 库配置的大致思路如下伪代码具体寄存器名以参考手册为准__ALIGNED(8) LLI_TypeDef lli_list[3]; /* 节点0发送包头 */ lli_list[0].src_addr (uint32_t)packet_header; lli_list[0].dst_addr (uint32_t)UART_TX_REG; lli_list[0].transf_len sizeof(packet_header); lli_list[0].ctrl LLI_CTRL_8BIT | LLI_CTRL_NEXT_LLI(lli_list[1]); lli_list[0].next_lli (uint32_t)lli_list[1]; /* 节点1发送负载 */ lli_list[1].src_addr (uint32_t)payload_buf; lli_list[1].dst_addr (uint32_t)UART_TX_REG; lli_list[1].transf_len payload_len; lli_list[1].ctrl LLI_CTRL_8BIT | LLI_CTRL_NEXT_LLI(lli_list[2]); lli_list[1].next_lli (uint32_t)lli_list[2]; /* 节点2发送CRC */ lli_list[2].src_addr (uint32_t)crc_value; lli_list[2].dst_addr (uint32_t)UART_TX_REG; lli_list[2].transf_len 4; lli_list[2].ctrl LLI_CTRL_32BIT | LLI_CTRL_LAST_LLI; lli_list[2].next_lli 0;这样配置好之后CPU 只需要写一次 GPDMA 控制寄存器后续整个数据包的发送都由硬件自动完成发送完成中断触发时三个缓冲区已经全部搬完了。整个过程没有任何内存拷贝延迟低RAM 开销也小。对于报文协议比较复杂的产品这个能力非常实用。4. CubeMXHAL快速上手串口不定长接收4.1 图形化配置关键点U5 系列的开发我一般习惯从 CubeMX 开始先把外设时钟和引脚关系理清楚再去看生成的代码。配置 GPDMA 时重点看这几个选项在 DMA Settings 页面点击 Add选择你要服务的外设请求比如 USART1_RX。DMA Request 下拉框里选择 GPDMA 对应的请求源注意别选到 LPDMA 上去。Direction 选择 Peripheral To Memory。数据宽度根据外设寄存器位宽选择UART 一般选 Byte。Priority 根据实时性要求选择中断处理频繁的外设建议 High。如果打算用链表模式在下方勾选 Linked-list Mode然后在代码里准备描述符。生成代码以后HAL 库会为你创建一个 DMA 句柄并在外设初始化里调用HAL_DMA_Init。这里要注意U5 的 HAL 库里 DMA 句柄类型和老系列不完全一样千万别直接照抄 F4 的代码接口命名和参数都有可能变过。4.2 代码改动点与回调串口不定长接收是工程里非常典型的场景。传统的做法是“固定长度接收 定时器超时判断”但更省心的方案是“UART 空闲中断 GPDMA 循环接收”。在 CubeMX 里把 USART 的全局中断和 GPDMA 中断都打开然后用HAL_UARTEx_ReceiveToIdle_DMA启动接收。这个 API 的意思是启动 DMA 接收直到收到指定长度或总线上出现空闲状态时停止。代码逻辑大概长这样#define RX_BUF_SIZE 256 uint8_t rx_buf[RX_BUF_SIZE]; // 启动接收 HAL_UARTEx_ReceiveToIdle_DMA(huart1, rx_buf, RX_BUF_SIZE); // 接收事件回调 void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { if (huart-Instance USART1) { // Size 是本次接收到的数据长度 ProcessIncomingFrame(rx_buf, Size); // 重新启动下一次接收 HAL_UARTEx_ReceiveToIdle_DMA(huart1, rx_buf, RX_BUF_SIZE); } }这里有一个细节回调里拿到的Size是本次空闲事件发生时已经接收到的字节数。如果使能了半传输中断回调可能触发两次需要在状态标志里区分是半传输还是传输完成避免在数据还没接收完整时就去处理半包数据。我习惯在代码里定义一个volatile uint8_t dma_rx_complete_flag在回调里置位在主循环里轮询处理逻辑会更清晰。4.3 直接跑个内存拷贝实验配置了这么半天怎么确认 GPDMA 真的在工作我建议先抛开外设做一个最简单的内存到内存拷贝实验。整个过程不涉及外设请求纯粹用软件触发非常适合验证 GPDMA 的链路是否打通。#define BUF_SIZE 1024 uint32_t src_buf[BUF_SIZE]; uint32_t dst_buf[BUF_SIZE]; // 填充源缓冲区 for (int i 0; i BUF_SIZE; i) { src_buf[i] i; } // 启动 DMA 内存拷贝 HAL_DMA_Start(hdma_gpdma, (uint32_t)src_buf, (uint32_t)dst_buf, BUF_SIZE * 4); HAL_DMA_PollForTransfer(hdma_gpdma, HAL_DMA_FULL_TRANSFER, 1000); // 校验结果 int ok 1; for (int i 0; i BUF_SIZE; i) { if (src_buf[i] ! dst_buf[i]) { ok 0; break; } }这个实验跑通了说明 GPDMA 的时钟、总线访问、中断配置基本都是正常的后面再接外设请求心里就有底了。另外提个醒在使能了 D-Cache 的情况下DMA 和 CPU 之间的缓存一致性必须考虑。如果 D-Cache 是开启的DMA 搬运的数据可能被缓存在 Cache 里没有写回导致 CPU 读到的还是旧数据。U5 内部有相关的维护机制和编程接口实际工程里不要忽视这个点否则排查起来会很痛苦。5. 低功耗配合与调试排雷5.1 GPDMA和低功耗模式的边界STM32U575-585 主打超低功耗Stop 模式下面还有 Stop 0、Stop 1、Stop 2 等多个档位。搞不清 GPDMA 在哪个模式下还能干活是很多低功耗项目返工的原因。从架构设计上看GPDMA 需要系统时钟保持在运行状态才能工作所以它只能在 Run 模式、Sleep 模式以及部分浅睡眠模式下正常工作。一旦进入 Stop 2 这种深睡眠状态GPDMA 的时钟被切断通道状态全部冻结无法继续搬运数据。LPDMA 则不同它被设计为可以在低功耗模式下继续服务配合支持低功耗运行的外设可以在 MCU 深度睡眠时依然完成数据采集和搬运。实际项目管理上我的策略是这样的系统正常运行时所有数据搬运任务统一走 GPDMA吞吐率高、通道多、配置灵活在进入 Stop 2 之前把需要在低功耗状态下保持工作的外设比如低功耗 UART 的唤醒帧接收、传感器的周期性数据采集切换到 LPDMA 通道然后 CPU 再进入深度睡眠。唤醒之后再把外设重新切回 GPDMA。虽然切换的代码量不大但两类 DMA 句柄不能混用这点在写驱动时一定要设计清楚。5.2 常用调试方法GPDMA 出问题时最典型的特征是外设数据就是不出来或者数据是乱的。排查时我一般按下面几步走先确认 GPDMA 是否真的被触发。把传输完成中断打开在回调里翻转某个 GPIO用逻辑分析仪看波形。有波形说明触发链路是通的问题出在数据配置上没波形说明触发源或者通道配置不对。检查源地址和目的地址是否合法。访问了非法地址GPDMA 会直接报总线错误数据搬运直接中止。检查数据宽度和缓冲区大小是否匹配。UART 是 8 位数据寄存器你却把源数据宽度配成了 32 位那采集到的数据就会错位。如果启用了链表模式优先检查描述符地址对齐和链表结尾标志。链表描述符一旦损坏GPDMA 的行为会变得非常诡异。调试时还有个小坑当你用仿真器停在断点调试时GPDMA 可能会因为时钟被冻结而停止工作。这时候需要看调试配置里是否有“Debug in low power mode”相关的选项或者手动配置 DBGMCU 寄存器让 GPDMA 在调试暂停时也保持状态。不然你断点一停外设数据流就断了查了半天以为是代码问题其实是调试器把 DMA 冻住了。5.3 常见错误速查与性能调优现象可能原因处理建议DMA传输没有启动未使能通道、请求源配置错误检查通道控制寄存器的使能位确认请求映射数据传输到一半停止总线错误、地址越界检查源/目的地址是否落在有效内存区域接收到数据乱码数据宽度不匹配、字节序错误核对外设寄存器宽度调整源和目的位宽链表模式只执行第一个任务下一个LLI指针为0或无效检查每个LLI的next指针是否正确链到下一个断点调试时DMA停止调试模式下时钟被冻结配置DBGMCU保持DMA时钟运行开启Cache后数据不对DMA与Cache一致性问题性能允许时关闭D-Cache或做一致性维护性能调优方面GPDMA 的优先级分为低、中、高、非常高四档。串口这类对实时性要求不高但流量均匀的外设用中优先级就够了音频 I2S 这类需要连续不间断传输的外设建议给高优先级不然容易被其他 DMA 任务挤占总线造成数据断流。还有一个建议不是所有数据搬运都值得用 GPDMA。DMA 是有启动开销的配置寄存器需要时间传输完成中断也有延迟。如果只是搬运几十个字节CPU 直接 memcpy 可能比 DMA 更快功耗也更低。我的经验是数据量超过几百字节或者需要长时间连续采集的时候GPDMA 的优势才能真正体现出来。6. 我的几点实操心得折腾完这一圈我心里最深的感受是GPDMA 这套架构的学习成本并不低但它带来的灵活性是值得的。老 DMA 那种“固定通道、单任务、低功耗就歇菜”的模式在新一代 MCU 的复杂应用需求下已经不够用了链表描述符和请求复用器这两个特性在协议处理、多传感器采集这些常见场景里确实能简化软件设计同时降低 CPU 负载。最后分享一个我调试链表时的小技巧。链表模式最怕的就是“某个节点跳飞了”因为 GPDMA 是硬件在执行出错时很难定位是哪个节点出了问题。我习惯在每个 LLI 描述符的保留字段里写一个自己定义的 magic 值比如0xA5A5A5A5然后在传输完一轮后检查所有的 magic 值是否仍完整。一旦发现某个描述符的 magic 被改写就能立刻锁定是哪个节点产生了异常访问排查效率会高很多。这个方法已经帮我抓出过两次因为缓冲区越界导致描述符被踩的问题希望能给你提供一点参考。
最近两年做低功耗物联网的朋友应该都开始把目光往STM32U5系列上靠了。我第一次拿到STM32U575 的开发板时板子跑分确实漂亮TrustZone 也很唬人但真正让我心里一紧的是打开参考手册看到 DMA 那一章的时候——原来熟悉的 DMA1/DMA2 不见了取而代之的是一个叫 GPDMA、一个叫 LPDMA 的新家伙。说实话第一次接触 GPDMA 我有点懵寄存器不一样了中断回调变了还多了链表描述符这种以前只在高端芯片上见过的概念。把整套架构摸清楚之后我反倒觉得 ST 这步棋走得非常聪明GPDMA 负责常规的高性能搬运LPDMA 负责低功耗模式下的数据保活两条腿走路。这篇应用笔记就围绕 STM32U575-585 的 GPDMA把它的工作原理、配置方法和实际工程里的坑都摊开讲一讲给正在被 U5 的 DMA 搞头疼的朋友一份可以直接抄作业的参考。1. GPDMA到底“新”在哪从老DMA到U5的架构变化1.1 为什么ST要把DMA架构推倒重来STM32F1/F4 时代的老 DMA大家应该都很熟DMA1 有 7 个通道DMA2 有 5 个通道每个通道和外设的映射关系基本是写死的。你用 USART1_TX就只能用 DMA1 的通道 4想换通道不行那是硬件连接。这种固定映射在小工程里没啥问题但一旦外设一多通道分配表就得靠工程师手工拉 Excel 去排非常痛苦。到了 STM32U5 系列ST 直接把这套旧架构推倒重来了。原因也很直白U5 走的是超低功耗 高性能的定位老式 DMA 有几个硬伤解决不了老 DMA 的触发源固定缺乏灵活性面对 TrustZone 带来的安全/非安全总线隔离老架构很难平滑适配。老 DMA 在深度低功耗模式下基本歇菜U5 想实现 Stop 模式下外设依然能搬运数据需要为低功耗场景单独设计一套 DMA。老 DMA 一次只能配置一个传输任务多段不连续内存搬运必须靠 CPU 反复发起 DMA效率很低。所以 U5 上的 DMA 被拆成了两个角色GPDMA 负责系统正常运行时的通用搬运LPDMA 负责低功耗模式下继续工作。这就像一个大公司白天有主力物流车队干重活晚上有夜班小分队保证核心物资不断供。GPDMA 和 LPDMA 虽然都是 DMA但设计目标和寄存器模型并不完全一样后续配置时一定要区分清楚。1.2 GPDMA和LPDMA的分工很多新手拿到 U575 的参考手册看到 GPDMA 和 LPDMA 两个章节第一反应是“选一个用就行”。这里必须敲黑板两个都不是可选替代关系而是分工关系。对比项传统DMAF1/F4GPDMALPDMA定位常规外设搬运高性能常规搬运低功耗模式下的搬运通道数7/5通道通道资源充足支持多请求复用通道数较少够低功耗场景用触发源通道固定映射通过请求复用器灵活映射同样支持请求复用链表描述符不支持原生支持多个传输任务可串接同样支持低功耗模式Stop模式基本不可用深睡眠场景受限可在Stop 2等低功耗模式下保持工作数据传输宽度8/16/32位最高支持64位双字访问8/16/32位为主从这张表能看出来GPDMA 是主力运输队LPDMA 是低功耗值守小分队。实际项目里我通常的做法是系统活跃时的 ADC 采样、串口通信、SPI Flash 读写全部走 GPDMA进入 Stop 2 模式后需要保持工作的外设比如低功耗串口接收唤醒帧、传感器数据周期采集用 LPDMA 接管搬运工作。要特别提醒一句GPDMA 虽然名字里带“Generic”但并不意味着它在所有低功耗模式下都能跑。GPDMA 需要系统时钟在运行进入深度低功耗模式后它一样会停摆。所以千万别拿 GPDMA 去实现 Stop 模式下的数据保活那是 LPDMA 的地盘。2. GPDMA的“路由中枢”请求复用器与数据流配置2.1 请求复用器是什么老 DMA 是硬件固定映射U5 的 GPDMA 则引入了一个类似路由器的模块请求复用器DMAMUX。你不需要再关心“这个外设请求必须落到哪个通道”任何外设的请求都可以通过寄存器配置映射到任意一个 GPDMA 通道上。打个比方老 DMA 通道像写字楼里的固定停车位你的车只能停在那个专属车位别人占了你就没办法GPDMA 的复用器则像停车场调度系统不管车从哪个方向来只要车位空闲调度员就能把它引导过去。这样带来的直接好处是 PCB 和软件设计都灵活得多换外设通道时不再需要去核对那张映射表。实际使用上你在 CubeMX 里给某个外设添加 DMA 通道时图形界面会直接给出可选的 GPDMA 通道和请求源。比如给 USART1 的 RX 配置 GPDMA只需要在配置界面里选择对应的外设请求CubeMX 会自动完成通道分配和复用器配置不需要你手动去翻寄存器找请求号。但如果你用 LL 库或者直接操作寄存器就需要在代码里把请求源编号写到对应的通道请求选择寄存器里这部分就要看清楚参考手册里面的请求映射表了。2.2 外设请求与硬件触发GPDMA 的触发源和传统 DMA 一样分为三类软件触发、外设请求触发、硬件触发。软件触发最简单就是 CPU 发一条指令让 GPDMA 开始搬运典型场景是内存到内存的拷贝。外设请求触发是用的最多的外设 RX 缓冲区有数据了向 GPDMA 发一个请求GPDMA 就开始搬运搬运完一段外设再发请求GPDMA 再搬配合传输完成中断实现全自动的数据流处理。硬件触发这个功能就有点意思了。它把外部事件或定时器事件当做一个“门控信号”GPDMA 要等到门控信号来了才会执行一次传输。简单说外设请求负责告诉 GPDMA“有货要搬”硬件触发负责告诉 GPDMA“现在可以开始搬”。这种双条件机制非常适合固定的采样场景比如用定时器 PWM 波形触发 ADC 采样ADC 转换完成后产生请求GPDMA 把采样结果搬到内存整个过程完全不需要 CPU 干预时序也是硬实时保证的。我在实际项目里用过一个场景用高级定时器输出 PWM 驱动传感器同时在 PWM 的上升沿触发内部 ADC 采样采样结果通过 GPDMA 循环模式持续搬运到内存数组里。这样 CPU 只需要在后台做数据处理采样率能做到很高的稳定性。2.3 数据宽度、方向与突发GPDMA 支持 8 位、16 位、32 位、64 位四种数据宽度。这里要特别注意源和目的的数据宽度可以不一致GPDMA 会自动做位宽转换。比如从 8 位的 UART 数据寄存器读取数据搬运到 32 位的内存缓冲区GPDMA 会把每 4 个字节组合成一个 32 位字写入内存。这种情况下要留意字节序和填充方式否则数据组包错位排查起来很坑。突发传输Burst是 GPDMA 提升带宽的重要特性。突发长度支持 1、4、8 和 16也就是一次突发连续搬 4 个、8 个或 16 个数据单元。突发传输适合源或者目的地址是对齐的场景比如把整块 Flash 数据搬运到 SRAM突发模式能充分利用总线带宽。但如果不是对齐的地址突发传输可能会触发错误这点在协议缓冲区不固定的场景下要特别注意。一个性能优化的心得U5 内核和总线本身支持 64 位访问如果你搬运的数据量大尽量把源地址、目的地址和数据长度都按双字8字节对齐然后在 CubeMX 里把数据宽度选成 64 位、突发长度设为 4 或 8。实测下来在大量数据拷贝场景下相比 32 位非突发配置带宽能提升接近一倍。不过小数据量传输就别折腾了突发模式带来的配置开销可能比数据传输本身还大反而得不偿失。3. 链表描述符LLI一个描述符串起多个传输任务3.1 链表模式解决了什么问题传统 DMA 每个通道一次只能执行一个传输任务这个任务做完要么停下来等 CPU 重新配置要么依赖循环模式不断重复同一块缓冲区。遇到“三段不连续内存拼成一包数据发出去”这种需求老办法只能先在 RAM 里开一个大 buffer用 CPU 把三段数据 memcpy 到一起再开启一次 DMA 发送。这个过程既浪费 RAM又增加延迟。GPDMA 的链表模式Linked-list Mode就是来解决这个痛点的。它允许你把多个传输任务用链表节点串起来每个节点描述一个独立的传输操作包括源地址、目的地址、传输长度、控制参数以及下一个节点的地址。GPDMA 自动完成第一个任务后会顺着指针跑到下一个节点继续执行全部执行完再触发完成中断。如果你熟悉快递配送这个模式就很好懂普通 DMA 叫“单程出租车”你告诉司机去一个地方到了就结束链表模式是“接力配送单”每个配送站都贴着下一站的地址和货物清单快递员到了一个站照着清单和下一站地址继续跑直到完成整个线路。做协议栈的时候这个功能真的能省掉大量内存拷贝。3.2 LLI描述符的内容与内存摆放一个 LLI 描述符在内存里本质上就是一组结构体字段核心内容包含源地址SRC_ADD本次传输的起始源地址。目的地址DST_ADD本次传输的目的起始地址。传输长度TRANSF_LEN本次传输的数据量。控制字CTRL数据宽度、突发长度、传输模式等配置。下一个LLI指针NEXT_LLI指向下一个描述符的地址如果是最后一个节点可以配置为 0 表示结束。描述符本身需要放在 RAM 中因为 GPDMA 在执行过程中要读它。这里有个容易踩的坑如果没有使能 Cache或者 Cache 策略配置不当描述符更新后 GPDMA 可能读到旧数据导致链表乱跳甚至卡死。还有一个关键点是内存对齐。GPDMA 要求 LLI 描述符的地址按照其读取宽度对齐通常建议至少 4 字节对齐最好 8 字节对齐。我习惯在代码里用__ALIGNED(8)来声明描述符数组防止编译器把它分配到一个诡异的位置。3.3 实操三段内存拼接发送我举个实际例子。设备上报数据时数据包是“包头 负载 CRC”三段分别存放在三个不同的缓冲区里。传统做法是先把它们拷贝到一个连续发送缓冲区再启动 DMA 发送。有了链表模式我直接配置三个 LLI 节点依次指向包头、负载和 CRC 缓冲区然后启动 GPDMA它就会自动把三段数据连续发出去。用 LL 库配置的大致思路如下伪代码具体寄存器名以参考手册为准__ALIGNED(8) LLI_TypeDef lli_list[3]; /* 节点0发送包头 */ lli_list[0].src_addr (uint32_t)packet_header; lli_list[0].dst_addr (uint32_t)UART_TX_REG; lli_list[0].transf_len sizeof(packet_header); lli_list[0].ctrl LLI_CTRL_8BIT | LLI_CTRL_NEXT_LLI(lli_list[1]); lli_list[0].next_lli (uint32_t)lli_list[1]; /* 节点1发送负载 */ lli_list[1].src_addr (uint32_t)payload_buf; lli_list[1].dst_addr (uint32_t)UART_TX_REG; lli_list[1].transf_len payload_len; lli_list[1].ctrl LLI_CTRL_8BIT | LLI_CTRL_NEXT_LLI(lli_list[2]); lli_list[1].next_lli (uint32_t)lli_list[2]; /* 节点2发送CRC */ lli_list[2].src_addr (uint32_t)crc_value; lli_list[2].dst_addr (uint32_t)UART_TX_REG; lli_list[2].transf_len 4; lli_list[2].ctrl LLI_CTRL_32BIT | LLI_CTRL_LAST_LLI; lli_list[2].next_lli 0;这样配置好之后CPU 只需要写一次 GPDMA 控制寄存器后续整个数据包的发送都由硬件自动完成发送完成中断触发时三个缓冲区已经全部搬完了。整个过程没有任何内存拷贝延迟低RAM 开销也小。对于报文协议比较复杂的产品这个能力非常实用。4. CubeMXHAL快速上手串口不定长接收4.1 图形化配置关键点U5 系列的开发我一般习惯从 CubeMX 开始先把外设时钟和引脚关系理清楚再去看生成的代码。配置 GPDMA 时重点看这几个选项在 DMA Settings 页面点击 Add选择你要服务的外设请求比如 USART1_RX。DMA Request 下拉框里选择 GPDMA 对应的请求源注意别选到 LPDMA 上去。Direction 选择 Peripheral To Memory。数据宽度根据外设寄存器位宽选择UART 一般选 Byte。Priority 根据实时性要求选择中断处理频繁的外设建议 High。如果打算用链表模式在下方勾选 Linked-list Mode然后在代码里准备描述符。生成代码以后HAL 库会为你创建一个 DMA 句柄并在外设初始化里调用HAL_DMA_Init。这里要注意U5 的 HAL 库里 DMA 句柄类型和老系列不完全一样千万别直接照抄 F4 的代码接口命名和参数都有可能变过。4.2 代码改动点与回调串口不定长接收是工程里非常典型的场景。传统的做法是“固定长度接收 定时器超时判断”但更省心的方案是“UART 空闲中断 GPDMA 循环接收”。在 CubeMX 里把 USART 的全局中断和 GPDMA 中断都打开然后用HAL_UARTEx_ReceiveToIdle_DMA启动接收。这个 API 的意思是启动 DMA 接收直到收到指定长度或总线上出现空闲状态时停止。代码逻辑大概长这样#define RX_BUF_SIZE 256 uint8_t rx_buf[RX_BUF_SIZE]; // 启动接收 HAL_UARTEx_ReceiveToIdle_DMA(huart1, rx_buf, RX_BUF_SIZE); // 接收事件回调 void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { if (huart-Instance USART1) { // Size 是本次接收到的数据长度 ProcessIncomingFrame(rx_buf, Size); // 重新启动下一次接收 HAL_UARTEx_ReceiveToIdle_DMA(huart1, rx_buf, RX_BUF_SIZE); } }这里有一个细节回调里拿到的Size是本次空闲事件发生时已经接收到的字节数。如果使能了半传输中断回调可能触发两次需要在状态标志里区分是半传输还是传输完成避免在数据还没接收完整时就去处理半包数据。我习惯在代码里定义一个volatile uint8_t dma_rx_complete_flag在回调里置位在主循环里轮询处理逻辑会更清晰。4.3 直接跑个内存拷贝实验配置了这么半天怎么确认 GPDMA 真的在工作我建议先抛开外设做一个最简单的内存到内存拷贝实验。整个过程不涉及外设请求纯粹用软件触发非常适合验证 GPDMA 的链路是否打通。#define BUF_SIZE 1024 uint32_t src_buf[BUF_SIZE]; uint32_t dst_buf[BUF_SIZE]; // 填充源缓冲区 for (int i 0; i BUF_SIZE; i) { src_buf[i] i; } // 启动 DMA 内存拷贝 HAL_DMA_Start(hdma_gpdma, (uint32_t)src_buf, (uint32_t)dst_buf, BUF_SIZE * 4); HAL_DMA_PollForTransfer(hdma_gpdma, HAL_DMA_FULL_TRANSFER, 1000); // 校验结果 int ok 1; for (int i 0; i BUF_SIZE; i) { if (src_buf[i] ! dst_buf[i]) { ok 0; break; } }这个实验跑通了说明 GPDMA 的时钟、总线访问、中断配置基本都是正常的后面再接外设请求心里就有底了。另外提个醒在使能了 D-Cache 的情况下DMA 和 CPU 之间的缓存一致性必须考虑。如果 D-Cache 是开启的DMA 搬运的数据可能被缓存在 Cache 里没有写回导致 CPU 读到的还是旧数据。U5 内部有相关的维护机制和编程接口实际工程里不要忽视这个点否则排查起来会很痛苦。5. 低功耗配合与调试排雷5.1 GPDMA和低功耗模式的边界STM32U575-585 主打超低功耗Stop 模式下面还有 Stop 0、Stop 1、Stop 2 等多个档位。搞不清 GPDMA 在哪个模式下还能干活是很多低功耗项目返工的原因。从架构设计上看GPDMA 需要系统时钟保持在运行状态才能工作所以它只能在 Run 模式、Sleep 模式以及部分浅睡眠模式下正常工作。一旦进入 Stop 2 这种深睡眠状态GPDMA 的时钟被切断通道状态全部冻结无法继续搬运数据。LPDMA 则不同它被设计为可以在低功耗模式下继续服务配合支持低功耗运行的外设可以在 MCU 深度睡眠时依然完成数据采集和搬运。实际项目管理上我的策略是这样的系统正常运行时所有数据搬运任务统一走 GPDMA吞吐率高、通道多、配置灵活在进入 Stop 2 之前把需要在低功耗状态下保持工作的外设比如低功耗 UART 的唤醒帧接收、传感器的周期性数据采集切换到 LPDMA 通道然后 CPU 再进入深度睡眠。唤醒之后再把外设重新切回 GPDMA。虽然切换的代码量不大但两类 DMA 句柄不能混用这点在写驱动时一定要设计清楚。5.2 常用调试方法GPDMA 出问题时最典型的特征是外设数据就是不出来或者数据是乱的。排查时我一般按下面几步走先确认 GPDMA 是否真的被触发。把传输完成中断打开在回调里翻转某个 GPIO用逻辑分析仪看波形。有波形说明触发链路是通的问题出在数据配置上没波形说明触发源或者通道配置不对。检查源地址和目的地址是否合法。访问了非法地址GPDMA 会直接报总线错误数据搬运直接中止。检查数据宽度和缓冲区大小是否匹配。UART 是 8 位数据寄存器你却把源数据宽度配成了 32 位那采集到的数据就会错位。如果启用了链表模式优先检查描述符地址对齐和链表结尾标志。链表描述符一旦损坏GPDMA 的行为会变得非常诡异。调试时还有个小坑当你用仿真器停在断点调试时GPDMA 可能会因为时钟被冻结而停止工作。这时候需要看调试配置里是否有“Debug in low power mode”相关的选项或者手动配置 DBGMCU 寄存器让 GPDMA 在调试暂停时也保持状态。不然你断点一停外设数据流就断了查了半天以为是代码问题其实是调试器把 DMA 冻住了。5.3 常见错误速查与性能调优现象可能原因处理建议DMA传输没有启动未使能通道、请求源配置错误检查通道控制寄存器的使能位确认请求映射数据传输到一半停止总线错误、地址越界检查源/目的地址是否落在有效内存区域接收到数据乱码数据宽度不匹配、字节序错误核对外设寄存器宽度调整源和目的位宽链表模式只执行第一个任务下一个LLI指针为0或无效检查每个LLI的next指针是否正确链到下一个断点调试时DMA停止调试模式下时钟被冻结配置DBGMCU保持DMA时钟运行开启Cache后数据不对DMA与Cache一致性问题性能允许时关闭D-Cache或做一致性维护性能调优方面GPDMA 的优先级分为低、中、高、非常高四档。串口这类对实时性要求不高但流量均匀的外设用中优先级就够了音频 I2S 这类需要连续不间断传输的外设建议给高优先级不然容易被其他 DMA 任务挤占总线造成数据断流。还有一个建议不是所有数据搬运都值得用 GPDMA。DMA 是有启动开销的配置寄存器需要时间传输完成中断也有延迟。如果只是搬运几十个字节CPU 直接 memcpy 可能比 DMA 更快功耗也更低。我的经验是数据量超过几百字节或者需要长时间连续采集的时候GPDMA 的优势才能真正体现出来。6. 我的几点实操心得折腾完这一圈我心里最深的感受是GPDMA 这套架构的学习成本并不低但它带来的灵活性是值得的。老 DMA 那种“固定通道、单任务、低功耗就歇菜”的模式在新一代 MCU 的复杂应用需求下已经不够用了链表描述符和请求复用器这两个特性在协议处理、多传感器采集这些常见场景里确实能简化软件设计同时降低 CPU 负载。最后分享一个我调试链表时的小技巧。链表模式最怕的就是“某个节点跳飞了”因为 GPDMA 是硬件在执行出错时很难定位是哪个节点出了问题。我习惯在每个 LLI 描述符的保留字段里写一个自己定义的 magic 值比如0xA5A5A5A5然后在传输完一轮后检查所有的 magic 值是否仍完整。一旦发现某个描述符的 magic 被改写就能立刻锁定是哪个节点产生了异常访问排查效率会高很多。这个方法已经帮我抓出过两次因为缓冲区越界导致描述符被踩的问题希望能给你提供一点参考。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
