1. 从一次深夜调试说起
凌晨两点半，显示器蓝光映在布满血丝的眼睛上。我盯着示波器上那个诡异的波形，第37次按下启动键——系统再次卡死在DMA传输完成中断里。这已经是本周第三次为这个内存拷贝问题熬夜，咖啡杯旁散落着写满寄存器地址的便签纸。作为嵌入式老鸟，我原以为DMA这种基础外设早就玩透了，直到这次项目让我重新认识了"直接内存访问"五个字的分量。
DMA（Direct Memory Access）就像个沉默的搬运工，在CPU不知情的情况下悄悄搬动数据。教科书上说它能"提升系统效率"，但没人告诉你当这个搬运工突然罢工时，排查起来有多酸爽。这次遇到的问题很典型：一个看似简单的内存拷贝操作，在启用DMA后竟导致整个系统随机挂死。通过这次踩坑，我想分享些教科书上找不到的实战经验。
2. DMA核心原理拆解
2.1 总线仲裁机制
DMA本质上是个"代班司机"。当它工作时，会通过总线仲裁器向CPU申请总线控制权。以STM32的AHB总线矩阵为例，其优先级顺序是：
- CPU指令取指
- CPU数据访问
- DMA1通道
- DMA2通道
我曾遇到过因仲裁优先级设置不当，导致DMA与CPU频繁争抢总线引发的死锁。具体表现为DMA传输完成中断标志已置位，但CPU就是读不到数据。解决方法是在初始化时配置DMA_CCRx寄存器中的PL[1:0]位，将关键通道设为最高优先级。
2.2 传输触发方式
常见触发方式对比表：
| 触发类型 | 适用场景 | 潜在坑点 |
|---|---|---|
| 软件触发 | 单次批量传输 | 需手动清除TC标志防重复触发 |
| 硬件外设触发 | ADC采集等周期性任务 | 时钟未使能会导致"静默失败" |
| 内存到内存模式 | 大数据块搬运 | 需确保源/地址对齐 |
那次深夜调试的问题就出在这里——我误将定时器触发的DMA配置成了软件触发，导致传输时序错乱。用逻辑分析仪抓取DMA_REQ信号后才恍然大悟。
2.3 传输完成判定
DMA传输完成的判定远比想象中复杂。除了检查TC（传输完成）标志位，还要注意：
- 剩余数据计数器（CNDTR）必须为0
- 对于循环模式，HT（半传输）标志也可能被误判
- 某些芯片存在寄存器读写同步延迟（尤其跨时钟域时）
我在排查中发现，有时CNDTR已经为0但TC标志未置位，后来发现是DMA时钟与内核时钟不同步导致的。解决方法是在读取状态前插入__DSB()内存屏障指令。
3. 内存拷贝的魔鬼细节
3.1 地址对齐陷阱
那次导致熬夜的bug，根源在于未对齐访问。当源地址是0x2000_0001而目标地址是0x2000_1000时（字节对齐），STM32的DMA会静默失败。后来我养成了在DMA启动前必做地址检查的习惯：
c复制// 检查32位对齐
assert((src_addr & 0x3) == 0);
assert((dst_addr & 0x3) == 0);
不同芯片的对齐要求差异很大：
- Cortex-M0/M0+：必须按字对齐
- Cortex-M3/M4：支持非对齐但性能下降
- 某些DSP芯片：要求128位对齐
3.2 缓存一致性处理
当使用带Cache的MPU时（如STM32H7），必须注意：
- 传输前Clean源地址Cache（确保数据最新）
- 传输后Invalidate目标地址Cache（防止读取旧值）
我曾遇到过DMA传输后内存数据已更新，但CPU读到的仍是Cache旧值的灵异事件。现在我的代码里必定包含如下操作：
c复制SCB_CleanDCache_by_Addr((uint32_t*)src, len);
// 启动DMA传输...
while(DMA_GetFlagStatus() == RESET);
SCB_InvalidateDCache_by_Addr((uint32_t*)dst, len);
3.3 传输长度计算
长度寄存器通常有两个限制：
- 最大计数值（如65535）
- 必须为传输粒度的整数倍（字节/半字/字）
一个隐蔽的坑是：当设置传输长度1000字节，但数据宽度配置为半字（2字节）时，实际只会传输500次。我现在的做法是：
c复制#define SAFE_DMA_LEN(bytes, width) \
((bytes) / (width) + (((bytes) % (width)) ? 1 : 0))
4. 调试技巧与实战记录
4.1 诊断工具链
我的调试三板斧：
- 逻辑分析仪：抓取DMA_REQ/ACK信号时序
- 内存断点：在目标地址设置硬件断点
- 寄存器差异对比：用脚本比较正常/异常时的寄存器快照
有个鲜为人知的技巧：在Keil调试器中，可以在DMA中断里添加以下代码实时查看传输状态：
c复制printf("DMA Err: %X Remaining: %d\n",
DMAx->ISR, DMAx_Channely->CNDTR);
4.2 常见错误代码
整理了几个经典错误现象及对策：
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| DMA中断不触发 | 中断线未映射/优先级太低 | 检查NVIC配置和中断向量表 |
| 传输数据错位 | 数据宽度配置不一致 | 统一源/目标的位宽设置 |
| 随机丢失最后几个字节 | 未处理TEIF错误标志 | 在中断中增加错误状态判断 |
| 系统卡死在DMA中断 | 未清除传输完成标志 | 在ISR起始处先清除所有标志位 |
4.3 性能优化实践
通过实测发现几个优化点：
- 使用双缓冲技术可将吞吐量提升40%
- 合理设置突发长度（如16字节）能减少总线占用
- 对于分散-聚集传输，链表模式比重复配置更高效
一个实测案例：在STM32H750上搬运1MB数据：
- 传统单次传输：耗时28ms
- 双缓冲+突发传输：耗时16ms
5. 不同芯片的DMA特性
5.1 STM32系列差异
以F1/F4/H7为例的关键区别：
| 特性 | STM32F1 | STM32F4 | STM32H7 |
|---|---|---|---|
| 通道数 | 7 | 8 | 16 |
| 数据位宽 | 最大32位 | 最大32位 | 支持64位 |
| 突发传输 | 不支持 | 支持 | 支持智能打包 |
| 链表模式 | 无 | 无 | 支持DMA2D |
5.2 其他厂商实现
NXP的eDMA有个独特设计：通道优先级可动态调整。这在多任务场景下非常有用，可以通过设置PREEMPT字段实现抢占式传输。
瑞萨RA系列的DMA则支持"传输组"概念，可以原子性地管理多个通道的启停，这在复杂时序控制中很实用。
6. 高级应用场景
6.1 零拷贝网络栈
在LWIP协议栈中，通过精心设计DMA描述符链表，可以实现：
- 网卡接收数据直接DMA到应用缓冲区
- 发送数据时无需从应用层拷贝到驱动层
实测在100Mbps以太网通信中，这种方式可降低30%的CPU占用率。
6.2 图像处理加速
使用STM32的DMA2D加速图像混合操作：
c复制DMA2D->FGMAR = (uint32_t)foreground;
DMA2D->BGMAR = (uint32_t)background;
DMA2D->OMAR = (uint32_t)output;
DMA2D->FGOR = stride;
DMA2D->CR = DMA2D_R2M | DMA2D_START;
如此实现800x480的ARGB8888混合仅需5ms（480MHz主频下）。
6.3 音频流处理
结合双缓冲和DMA半传输中断，可以实现无间隙音频播放：
- 前半传输完成中断：填充后半缓冲区
- 后半传输完成中断：填充前半缓冲区
关键是要精确计算缓冲大小，使其等于DMA传输周期的整数倍，否则会出现轻微爆音。