1. 从一个让人抓狂的现象说起搞嵌入式或者底层驱动开发的朋友大概率都遇到过这种场景外设通过DMA把数据搬到了内存里你满心欢喜地去读那块缓冲区结果读出来的还是上一次的旧值甚至干脆就是初始化时的全零。你反复检查DMA配置寄存器通道使能了传输长度也对源地址目的地址都没写错中断也正常触发了可CPU这边读到的数据就是不对。更诡异的是你用调试器单步跟踪或者加个打印语句数据又对了。这种薛定谔的DMA现象十有八九是Cache一致性在作祟。这篇文章就是围绕DMA读旧数据这个经典问题展开的。我会把Cache和DMA打架的底层原理讲透然后给出三套经过实战验证的解决方案从最简单的地址属性配置到手动维护Cache再到MPU/MMU层面的内存属性划分。内容会涉及Cortex-M7、Cortex-A系列这类带Cache的处理器也会提到一些不带Cache但带写缓冲的MCU场景。不管你是刚接触DMA的新手还是被Cache一致性问题折磨过的老手都能从里面找到可以直接抄作业的配置方法和排查思路。先说清楚适用人群如果你用的是STM32H7、RT1052、i.MX RT系列、树莓派这类带D-Cache的芯片或者在做Linux下的DMA驱动开发这篇文章基本就是为你写的。如果你用的是没有Cache的M0/M3内核那DMA读旧数据的概率会低很多但写缓冲和内存屏障的问题依然值得了解。下面我按为什么会这样到怎么解决的顺序把这件事彻底讲明白。2. DMA与Cache为什么会打架2.1 先搞懂DMA和Cache各自在干什么DMA的全称是直接内存访问它的核心价值就是让数据搬运这件事不经过CPU。比如串口收到一帧数据传统方式是CPU一个字节一个字节地从串口数据寄存器读出来再写到内存数组里这期间CPU啥也干不了。有了DMA你只需要告诉DMA控制器源地址是串口数据寄存器目的地址是内存里那块缓冲区长度是多少然后DMA自己就把数据搬完了搬完给你个中断。CPU在这期间可以去处理别的任务效率提升非常明显。Cache则是另一套逻辑。现代处理器的主频远高于内存访问速度CPU直接读内存会等很久。所以在CPU和主存之间加了一层容量小但速度极快的缓存也就是Cache。CPU读数据时先把内存里的一块数据按Cache Line为单位Cortex-M7通常是32字节Cortex-A常见64字节加载到Cache里下次再读同一块地址就直接从Cache拿不用访问内存。写数据时也有讲究有写穿和写回两种策略写回策略下CPU只改Cache不立刻写内存等Cache Line被替换时才写回去。问题就出在这里DMA搬运数据是直接操作内存的它不经过CPU自然也不经过Cache。而CPU读数据是经过Cache的。这就导致两边看到的内存视图可能不一致。2.2 一个生活化的类比帮你建立直觉你可以把主存想象成一个仓库Cache想象成你办公桌上的一个文件托盘。CPU是你本人DMA是一个跑腿的小哥。场景一跑腿小哥把新货物放进了仓库但你桌上托盘里还放着这个货位的旧清单。你伸手去拿拿的是托盘里的旧清单根本不知道仓库已经更新了。这就是DMA接收数据后CPU读到旧值的情况。场景二你在托盘里改了清单还没归档到仓库。跑腿小哥去仓库取货取到的是旧清单对应的旧货。这就是CPU写数据后DMA发送出去的是旧值的情况。场景三你桌上托盘里压根没有这个货位的清单你去仓库拿拿到的是最新的。这种情况反而没问题因为Cache没命中直接读内存了。这也解释了为什么有时候加个打印、单步调试数据就对了——那些操作可能触发了Cache行的替换或者刷新把旧数据挤出去了。这个类比基本能覆盖90%的Cache一致性问题。核心就一句话谁改了数据谁就要负责让另一方看到最新的。2.3 Cache Line是理解一切的关键单位很多人配置的时候只盯着地址忽略了Cache操作的最小单位是Cache Line不是单个字节。Cortex-M7的D-Cache Line是32字节Cortex-A9/A53这类通常是64字节。这意味着你调用Clean或者Invalidate操作时操作的是整个Line而不是你指定的那一个字节。这个特性会带来两个坑。第一个坑是伪共享你只想刷新自己那4个字节的变量结果把同一个Line里隔壁的变量也一起刷了如果隔壁变量正在被别的代码使用就可能出问题。第二个坑是地址对齐如果你要刷新的缓冲区起始地址没有按Cache Line对齐或者长度不是Line的整数倍那么Clean/Invalidate操作会波及到缓冲区前后的数据可能把不该刷的数据刷掉或者把刚写进去还没被DMA读走的数据给清了。所以你在定义DMA缓冲区的时候强烈建议用__attribute__((aligned(32)))或者ALIGN(64)这类方式做对齐长度也尽量凑成Line大小的整数倍。这个习惯能帮你省掉后面一大堆莫名其妙的bug。2.4 读旧数据到底发生在哪个环节把DMA传输拆成两个方向来看问题定位会更清晰。接收方向也就是外设到内存DMA把数据写进内存但CPU的Cache里可能还缓存着这块内存的旧内容。CPU去读的时候Cache命中直接返回旧值根本不去内存看DMA写的新数据。解决办法是在CPU读之前把对应的Cache Line无效化强制CPU下次读的时候去内存拿。发送方向也就是内存到外设CPU写数据到缓冲区如果用的是写回策略数据可能还在Cache里没落到内存。这时候你启动DMA发送DMA去内存读读到的是旧数据。解决办法是在启动DMA之前把对应的Cache Line清理把Cache里的新数据写回内存。还有一种混合场景DMA传输完成后CPU既要读新数据又可能之前往这块缓冲区写过东西。这时候需要先Clean再Invalidate顺序不能反。先Clean保证CPU的写操作落到内存再Invalidate保证CPU后续读能拿到DMA写的新数据。如果顺序反了Invalidate会把还没写回的数据直接丢弃造成数据丢失。3. 第一招把DMA缓冲区设为非缓存或写穿属性3.1 为什么这是最省心的方案解决Cache一致性问题最彻底的办法就是让这块内存压根不进Cache。数据不经过CacheDMA和CPU都直接访问内存自然就不存在一致性问题了。这就像你干脆不用那个文件托盘所有东西都直接去仓库拿虽然慢一点但绝对不会拿错。在Cortex-M7这类带MPU的芯片上你可以通过MPU把某一段内存区域配置成Non-cacheable。在Cortex-A系列带MMU的芯片上通过页表把对应页设为Non-cacheable或者Device属性。在Linux下用dma_alloc_coherent申请的内存默认就是非缓存的驱动开发者基本不用操心。这个方案的优势是零维护成本你不需要在每次DMA传输前后插入Clean/Invalidate操作代码逻辑简单不容易出错。代价是CPU访问这块内存的速度会下降因为每次都要走内存总线。但对于DMA缓冲区这种通常不会频繁被CPU大量访问的场景这个代价完全可以接受。3.2 Cortex-M7上用MPU配置非缓存区域的实操以常见的Cortex-M7芯片为例MPU配置一般分这几步。首先要确保MPU使能然后选择一个空闲的Region设置基地址、大小、访问权限和内存属性。内存属性里关键的是TEX、C、B这三个字段配置成Non-cacheable通常是把C位清零。/* 假设DMA缓冲区放在0x24000000大小64KB */ /* 配置MPU Region 0 */ MPU-RNR 0; /* 选择Region 0 */ MPU-RBAR 0x24000000 | MPU_RBAR_VALID_Msk; /* 基地址 */ MPU-RASR (0x0F MPU_RASR_SIZE_Pos) | /* 大小64KB2^(151) */ MPU_RASR_AP_FULL_ACCESS | /* 全权限 */ (0 MPU_RASR_TEX_Pos) | /* TEX0 */ (0 MPU_RASR_C_Pos) | /* C0非缓存 */ (0 MPU_RASR_B_Pos) | /* B0 */ MPU_RASR_ENABLE_Msk; /* 使能该Region */这里Size字段的计算方式是2的(SIZE1)次方字节。64KB是65536字节等于2的16次方所以SIZE填15。这个换算关系一定要算对填错了会导致覆盖范围不对可能把别的代码区域也变成非缓存影响性能甚至引发异常。配置完之后这块内存的访问就不走Cache了。你可以用一段简单的测试代码验证往这块内存写一个值然后直接读回来再用调试器看内存窗口如果两边一致且没有Cache行为干扰说明配置生效了。注意MPU Region的基地址必须按Region大小对齐。64KB的Region基地址必须是64KB对齐的也就是低16位为0。这个对齐要求经常被忽略导致配置不生效或者HardFault。3.3 写穿策略作为折中方案如果你既想要Cache带来的读性能又不想在DMA发送方向做Clean操作可以考虑把这块内存配成Write-through模式。写穿的意思是CPU每次写操作都同时更新Cache和内存这样内存里始终是最新数据DMA去读不会读到旧值。读方向依然走Cache性能损失比完全非缓存小。在MPU的RASR寄存器里Write-through对应的是C1、B0的组合。这个配置在接收方向依然需要Invalidate因为DMA写内存后Cache里的旧数据还在。所以写穿只解决了一半问题适合那些以发送为主、接收较少的场景。3.4 这个方案的适用边界和坑非缓存方案不是万能的。第一个坑是性能如果你的DMA缓冲区会被CPU频繁读写比如做大量数据处理的场景非缓存带来的性能下降可能很可观。这时候就要权衡或者考虑用第二招手动维护Cache。第二个坑是内存属性冲突。有些芯片的TCM内存或者某些特殊区域本身就不支持Cache你再去MPU里配一遍可能没效果或者报错。配置前最好查一下芯片参考手册里的内存映射表确认目标区域支持哪些属性。第三个坑是链接脚本。如果你用MPU配置了非缓存区域但链接脚本没把DMA缓冲区放到那个区域配置就白做了。通常的做法是在链接脚本里单独划一个section然后用__attribute__((section(.dma_buffer)))把变量放进去。这个section的地址要和MPU Region的基地址对应上。4. 第二招手动Clean和Invalidate Cache4.1 什么时候必须手动维护当你没法把DMA缓冲区设成非缓存比如内存区域被其他功能占用了或者你就是需要Cache带来的性能那就只能手动维护一致性。手动维护的核心就是在正确的时机调用正确的Cache操作函数。Cortex-M7上常用的函数有这么几个。SCB_CleanDCache_by_Addr把指定地址范围的Cache Line清理也就是把Cache里的脏数据写回内存。SCB_InvalidateDCache_by_Addr把指定范围的Cache Line无效化CPU下次读会去内存拿。SCB_CleanInvalidateDCache_by_Addr先Clean再Invalidate两个动作一起做。Cortex-A系列在裸机环境下也有类似的函数比如clean_dcache_area、invalidate_dcache_area。在Linux内核里驱动开发者用的是dma_sync_single_for_cpu、dma_sync_single_for_device这类封装好的接口底层会自动处理Cache操作。4.2 接收方向的正确操作顺序接收方向的流程是DMA把数据写进内存然后CPU去读。关键是在CPU读之前把对应Cache Line无效化。/* DMA接收完成中断里 */ void DMA_RxComplete_Handler(void) { /* 先无效化Cache让CPU能看到DMA写的新数据 */ SCB_InvalidateDCache_by_Addr((uint32_t *)rx_buffer, RX_BUFFER_SIZE); /* 然后再处理数据 */ process_data(rx_buffer, RX_BUFFER_SIZE); }这里有个细节要注意Invalidate操作必须在DMA传输完成之后做不能在启动DMA之前做。如果你在启动DMA前就Invalidate了DMA传输过程中CPU如果碰巧访问了这块内存又可能把旧数据加载进Cache等于白做。所以时机很重要。还有一个更隐蔽的坑如果CPU在DMA传输期间访问了接收缓冲区Cache里可能加载了旧数据。这时候DMA写内存然后你Invalidate看起来没问题。但如果Invalidate之前CPU又写了这块缓冲区Cache里是脏数据Invalidate会直接丢弃这些脏数据造成CPU的写操作丢失。所以接收缓冲区在DMA传输期间CPU最好不要去写它。4.3 发送方向的正确操作顺序发送方向的流程是CPU把数据写进缓冲区然后启动DMA发送。关键是在启动DMA之前把对应Cache Line清理确保数据落到内存。/* 准备发送数据 */ void prepare_tx_data(uint8_t *data, uint32_t len) { memcpy(tx_buffer, data, len); /* 清理Cache把数据写回内存 */ SCB_CleanDCache_by_Addr((uint32_t *)tx_buffer, TX_BUFFER_SIZE); /* 然后启动DMA */ DMA_StartTransfer(tx_buffer, TX_BUFFER_SIZE); }Clean操作必须在启动DMA之前做。如果先启动DMA再CleanDMA可能已经把旧数据读走了Clean就来不及了。这个顺序错误非常常见尤其是在中断里手忙脚乱的时候容易写反。4.4 地址对齐和长度处理的实际写法前面提过Cache Line对齐的问题这里给出一个实际的处理方法。假设你的缓冲区起始地址是0x20000004长度是100字节Cache Line是32字节。直接调用SCB_CleanDCache_by_Addr(0x20000004, 100)会怎样函数内部会从0x20000004所在的Line起始地址0x20000000开始一直处理到覆盖100字节所需的最后一个Line。也就是会处理0x20000000到0x2000007F这段共128字节。这意味着0x20000000到0x20000003这4个字节以及0x20000064到0x2000007F这28个字节也被一起Clean了。如果这些字节属于别的变量就可能造成问题。稳妥的做法是自己保证缓冲区对齐和长度取整。定义缓冲区时/* 32字节对齐长度取32的整数倍 */ __attribute__((aligned(32))) uint8_t rx_buffer[128];这样调用Clean/Invalidate时地址和长度都天然对齐不会波及无辜。如果实在没法对齐那就手动计算对齐后的起始地址和长度uint32_t start (uint32_t)buf ~(CACHE_LINE_SIZE - 1); uint32_t end ((uint32_t)buf len CACHE_LINE_SIZE - 1) ~(CACHE_LINE_SIZE - 1); SCB_CleanDCache_by_Addr((uint32_t *)start, end - start);这段代码把起始地址向下对齐结束地址向上对齐确保覆盖整个缓冲区。代价是可能多刷一点数据但至少不会漏刷。4.5 手动维护的常见翻车现场我见过最多的翻车是Clean和Invalidate用反。发送方向该Clean的用了Invalidate结果CPU写的数据被直接丢弃DMA发出去的是内存里的旧数据。接收方向该Invalidate的用了Clean结果Cache里的旧数据被写回内存把DMA刚写的新数据覆盖了。这两个错误都会导致数据错乱而且现象很随机很难查。第二个翻车是操作范围不对。有人只Clean了实际数据长度没考虑Cache Line对齐导致最后一个Line里的部分数据没写回。比如发了100字节只Clean了100字节但第100字节所在的Line里还有28字节没处理如果这28字节里有需要发送的数据就会出错。第三个翻车是在中断里做大量Cache操作。Clean/Invalidate本身是有开销的如果缓冲区很大在中断里做可能影响实时性。这时候可以考虑用DMA的双缓冲机制在后台处理Cache维护或者把缓冲区改小。5. 第三招用内存屏障和DMA双缓冲规避竞争5.1 内存屏障解决的是顺序问题Cache一致性解决的是看到的是不是最新数据内存屏障解决的是操作的顺序对不对。这两个问题经常一起出现但根因不同。考虑这个场景CPU先写了一个标志位告诉DMA可以开始了然后写数据缓冲区最后启动DMA。由于编译器和处理器都可能做指令重排实际执行顺序可能是先启动DMA再写数据再写标志位。DMA启动时数据还没准备好自然读到旧值。内存屏障就是用来阻止这种重排的。在Cortex-M上__DMB()是数据内存屏障保证屏障之前的内存访问先于屏障之后的完成。在写数据缓冲区和启动DMA之间插入一个DMB就能保证数据先写好。memcpy(tx_buffer, data, len); SCB_CleanDCache_by_Addr((uint32_t *)tx_buffer, TX_BUFFER_SIZE); __DMB(); /* 确保Clean操作完成后再启动DMA */ DMA_StartTransfer(tx_buffer, TX_BUFFER_SIZE);DMB和Cache操作配合使用才能既保证数据最新又保证顺序正确。很多人只做了Clean忘了DMB在大多数情况下也能工作但在高优化等级或者特定芯片上就可能出问题。5.2 DMA双缓冲如何减少Cache维护频率DMA双缓冲也叫乒乓缓冲的思路是准备两块缓冲区DMA在写A的时候CPU处理BDMA写满A切换到BCPU处理A。这样CPU和DMA可以并行工作吞吐量翻倍。从Cache角度看双缓冲的好处是Cache维护的时机更可控。你可以在DMA切换缓冲区的中断里对刚刚写满的那块缓冲区做Invalidate然后交给CPU处理。因为这块缓冲区在DMA写期间CPU不会碰所以Invalidate不会丢数据。void DMA_BufferSwitch_Handler(void) { if (current_buffer BUFFER_A) { /* B刚被DMA写满无效化B的Cache */ SCB_InvalidateDCache_by_Addr((uint32_t *)buffer_b, BUF_SIZE); process_buffer(buffer_b); /* 准备A给DMA继续写 */ SCB_CleanInvalidateDCache_by_Addr((uint32_t *)buffer_a, BUF_SIZE); } else { SCB_InvalidateDCache_by_Addr((uint32_t *)buffer_a, BUF_SIZE); process_buffer(buffer_a); SCB_CleanInvalidateDCache_by_Addr((uint32_t *)buffer_b, BUF_SIZE); } }注意这里对即将交给DMA的缓冲区用了CleanInvalidate先Clean把CPU可能残留的写操作落盘再Invalidate清掉旧数据确保DMA写进去的新数据不会被Cache里的旧数据干扰。5.3 用信号量或标志位协调CPU和DMA在多任务系统里DMA缓冲区的访问还需要考虑任务间的同步。比如一个任务负责处理DMA接收的数据另一个任务负责填充DMA发送的数据。如果两个任务同时操作同一块缓冲区Cache维护的时机就更难把握。常见的做法是用信号量或者原子标志位来标记缓冲区的状态。缓冲区有三种状态空闲、DMA占用、CPU占用。状态切换时做对应的Cache操作。比如从DMA占用切到CPU占用时做Invalidate从CPU占用切到DMA占用时做Clean。这个状态机看起来简单但实际写的时候容易漏掉状态切换的边界情况。比如DMA传输出错中断里也要做状态恢复和Cache维护否则下次传输可能用到脏数据。建议把Cache维护和状态切换封装成一个函数所有路径都走这个函数减少遗漏。5.4 这套方案的性能账怎么算手动维护Cache是有开销的。以Cortex-M7跑400MHz为例一次Invalidate操作大概几十到上百个时钟周期取决于缓冲区大小和Cache Line数量。如果每接收一帧数据都要Invalidate一次帧率又很高这个开销就不能忽略。粗略估算假设缓冲区1KBCache Line 32字节需要操作32个Line。每个Line的Invalidate大概几个周期加上函数调用开销一次操作可能在200周期左右。400MHz下就是0.5微秒。如果每秒接收1000帧就是0.5毫秒占CPU时间的0.02%基本可以忽略。但如果每秒接收100万帧那就是50%的CPU时间这时候就必须优化了。优化的方向有几个。一是增大缓冲区减少维护频率。二是用非缓存内存把开销转移到每次访问上但DMA缓冲区通常访问不频繁可能更划算。三是用DMA的Scatter-Gather模式让硬件帮忙管理缓冲区切换减少CPU干预。6. 常见问题排查速查表6.1 现象与可能原因对照现象可能原因排查方向DMA接收后CPU读到旧值Cache未Invalidate检查接收完成中断里是否有InvalidateDMA发送的是旧值Cache未Clean检查启动DMA前是否有Clean单步调试正常全速运行出错Cache一致性问题调试器可能触发了Cache刷新数据偶尔错乱不固定竞争条件或对齐问题检查缓冲区对齐和任务同步只有部分数据错Cache Line边界问题检查长度是否按Line对齐改了缓冲区大小后问题消失伪共享或对齐巧合检查相邻变量是否被波及高优化等级下出错低优化正常指令重排检查是否缺少内存屏障6.2 几个真实踩过的坑第一个坑是链接脚本和MPU配置不匹配。有个项目里MPU把0x24000000开始的64KB配成了非缓存但链接脚本把DMA缓冲区放在了0x20000000。结果配置完全没生效查了两天才发现是地址对不上。后来在链接脚本里加了专门的section问题解决。第二个坑是Invalidate把CPU刚写的数据冲掉了。接收缓冲区在DMA传输期间CPU因为处理别的逻辑碰巧写了一个字节进去然后DMA完成中断里Invalidate这个字节的写操作就丢了。后来改成接收缓冲区在DMA传输期间CPU绝对不写只读问题消失。第三个坑是Clean的范围不够。发送100字节只Clean了100字节但缓冲区定义是128字节最后28字节是上一次的残留数据。DMA发送时把这28字节也发出去了接收端解析出错。后来改成Clean整个缓冲区大小问题解决。第四个坑是忘了DMB。Clean之后直接启动DMA在低优化等级下没问题开了-O2之后偶尔出错。加了__DMB()之后稳定。这个坑的隐蔽性在于它依赖编译器和芯片的具体行为不是每次都能复现。6.3 一套通用的排查流程遇到DMA数据不对我一般按这个顺序排查。先确认DMA配置本身没问题用非缓存内存或者关闭Cache跑一遍如果数据对了那基本就是Cache问题。然后检查Cache维护的时机和方向接收方向有没有Invalidate发送方向有没有Clean顺序对不对。接着检查地址对齐和长度缓冲区起始地址和长度是否按Cache Line对齐。最后检查内存屏障和任务同步有没有指令重排或者竞争条件。这个流程能覆盖绝大多数情况。如果还搞不定那就用调试器看内存窗口和Cache窗口的对比直接观察数据在Cache和内存里的差异往往能一眼看出问题所在。7. 我个人的几条实操建议第一新项目一开始就把DMA缓冲区规划好。要么用非缓存内存要么用对齐的缓存内存加手动维护不要等到出了问题再改。前期多花十分钟后期省两天。第二Cache维护函数封装成宏或者内联函数把对齐处理、DMB、方向选择都包进去。这样调用的时候不容易写错也方便统一修改。比如封装一个dma_rx_sync(buf, len)和dma_tx_sync(buf, len)内部自动处理Clean/Invalidate和屏障。第三测试的时候一定要开最高优化等级跑长时间压力测试。Cache问题在低优化和短时间测试下经常不出现一上生产环境就爆发。我习惯用-O2或者-O3跑至少24小时的压力测试中间穿插各种边界条件。第四善用芯片的Cache维护寄存器。有些芯片提供了按地址范围维护Cache的硬件机制比软件循环效率高。比如某些Cortex-M7芯片有Cache维护寄存器组可以一次配置地址和长度硬件自动完成。查一下参考手册有的话就用上。第五文档里记一笔。Cache一致性问题的排查过程往往很曲折解决了之后一定要在代码注释或者项目文档里写清楚这块缓冲区为什么这么定义Cache维护为什么放在这个位置改动时要注意什么。不然过几个月自己都忘了下次改动可能又踩一遍。这些经验都是实际项目里一点点攒出来的希望能帮你少走点弯路。Cache和DMA的配合说复杂也复杂说简单也简单核心就是谁改了数据谁负责同步这一条。把这条记牢再结合具体的芯片手册和上面的三招基本就能搞定绝大多数场景了。