1. 从一个让人抓狂的现象说起搞嵌入式或者底层驱动开发的朋友大概率都遇到过这种场景外设通过DMA把数据搬运到内存里CPU这边满心欢喜地去读结果读到的全是上一轮的旧数据。明明DMA传输完成中断都触发了寄存器里的状态位也置起来了可内存里的内容就是纹丝不动像被冻住了一样。你加打印、加延时、甚至重启设备有时候好了有时候又不行神出鬼没。这个问题的根源十有八九出在Cache上。CPU访问内存走CacheDMA访问内存走总线两条路径看到的数据可能不一致。CPU以为内存里是新数据实际上Cache里缓存着旧值它直接从Cache拿根本不往内存那边看。DMA倒是老老实实把新数据写进了物理内存但CPU压根不知道这回事。这篇文章就是围绕这个经典问题展开的。我会把DMA与Cache不一致的底层原理讲透然后给出三套经过实际项目验证的解决方案从最简单的地址属性配置到手动维护Cache再到硬件一致性互联每一招都配上可操作的步骤和参数说明。不管你是刚接触DMA的新手还是被这个问题折磨过的老手都能从中找到可以直接抄作业的方案。2. 先把根子挖出来DMA和Cache为什么会打架2.1 一张图看懂数据通路的错位要理解这个问题得先搞清楚CPU、Cache、内存、DMA四者之间的数据流向。CPU读写数据时先看Cache里有没有。有就直接命中根本不碰内存没有才从内存加载到Cache再返回给CPU。DMA则不同它是个直肠子直接通过系统总线读写物理内存完全绕过Cache。这就埋下了一个隐患同一块内存地址可能存在两份数据副本。一份在Cache里是CPU最近访问过的一份在物理内存里是DMA刚写进去的。两份数据不一致谁也不知道该信谁。我画不了图但你可以这样想象Cache是CPU的私人笔记本内存是公司的公共白板。CPU要数据先翻自己的笔记本有就不去白板看了。DMA是快递员直接把新数据写到白板上但它不负责通知CPU更新笔记本。结果CPU一直抱着旧笔记本读白板上的新数据它根本看不见。2.2 写回与写通两种Cache策略的不同坑法Cache的写策略分两种写通和写回它们和DMA配合时出的问题还不一样。写通模式下CPU每次写数据既写Cache也写内存两者保持同步。这种模式下DMA读内存拿到的数据通常是最新的。但DMA写内存时如果CPU之前读过那块区域Cache里可能还留着旧副本CPU再读还是会命中旧数据。写回模式下CPU写数据只写Cache标记为脏行等到这行被替换出去时才写回内存。这种模式下问题更严重DMA读内存时CPU刚写的新数据可能还在Cache里没落盘DMA读到的是旧值DMA写内存后CPU读到的又可能是Cache里的旧副本。双向都可能不一致。实际项目中大多数高性能处理器默认用写回模式因为它的内存带宽占用更低。这也意味着Cache一致性问题更常见。2.3 什么情况下必须警惕Cache不一致不是所有DMA场景都会出问题以下几种情况是高发区遇到就要多留个心眼。第一种DMA缓冲区是可Cache的内存区域。如果这块内存被配置为CacheableCPU和DMA的访问路径就分叉了不一致几乎必然发生。第二种CPU在DMA传输前后访问过同一块缓冲区。比如先初始化缓冲区再启动DMA或者DMA完成后CPU立刻读数据这些访问都会在Cache里留下副本。第三种多核系统中不同核心访问同一缓冲区核间Cache同步本身就需要额外处理再加上DMA复杂度直接翻倍。反过来如果DMA缓冲区被配置为Non-Cacheable或者CPU在DMA传输期间完全没有碰过这块内存那通常不会出问题。但现实中很难保证CPU不碰所以还是得从机制上解决。3. 第一招把缓冲区设为Non-Cacheable从源头绕开3.1 原理与适用场景最直接的办法就是让CPU访问DMA缓冲区时不走Cache。既然Cache是罪魁祸首那不用它就行了。CPU每次读写都直接打到物理内存和DMA看到的是同一份数据自然不存在一致性问题。这种方案的优势是简单粗暴不需要在代码里插入任何维护操作配置一次就一劳永逸。缺点是性能有损失CPU访问这块内存的延迟会明显增加因为每次都要走总线。所以它适合DMA缓冲区不大、访问频率不高的场景比如串口收发缓冲、小批量ADC采样数据。如果缓冲区很大比如图像帧缓冲、高速数据采集的大块内存全部设为Non-Cacheable会让CPU处理数据时慢得让人难受。这时候就得考虑后面的方案。3.2 通过MMU页表配置内存属性在带MMU的处理器上内存的Cache属性是通过页表项来控制的。以ARM架构为例页表项里有几个关键位TEX、C、B。C位是Cacheable位B位是Bufferable位TEX配合C、B决定具体的内存类型。要把一块内存设为Non-Cacheable通常配置为Strongly-ordered或者Device类型也可以配置为Normal Non-Cacheable。具体做法是在页表中找到对应虚拟地址的页表项修改这些属性位然后刷新TLB让新配置生效。// 以某ARM处理器为例修改页表项属性的示意 // 假设pgtbl是页表基址vaddr是虚拟地址 uint32_t *pte get_pte(pgtbl, vaddr); *pte ~(0x3 2); // 清除C和B位 *pte | (0x1 2); // 设置为Normal Non-Cacheable flush_tlb(); // 刷新TLB这段代码只是示意实际处理器的页表格式和位定义差别很大一定要查对应芯片的TRM手册。我见过有人照着别的芯片改位偏移搞错了结果把内存设成了Device类型读写时序全乱调试了半天才发现。3.3 通过MPU配置内存属性没有MMU的处理器比如很多Cortex-M系列的MCU通常用MPU来配置内存属性。MPU可以把地址空间划分成若干个区域每个区域单独设置是否可Cache、是否可缓冲。以Cortex-M7为例它有两级CacheI-Cache和D-Cache。通过MPU的RBAR和RASR寄存器配置区域属性把DMA缓冲区所在的区域设为Non-Cacheable。// Cortex-M7 MPU配置示意 MPU-RBAR (buf_addr MPU_RBAR_ADDR_MASK) | MPU_RBAR_VALID_MASK | region_num; MPU-RASR MPU_RASR_ENABLE_MASK | MPU_RASR_ATTR_NON_CACHEABLE // 非Cache属性 | MPU_RASR_SIZE_64KB | MPU_RASR_AP_FULL_ACCESS;配置MPU时有个坑要注意区域大小必须是对齐的2的幂次比如4KB、8KB、16KB这样。如果你要保护的缓冲区是6KB那就得配成8KB多出来的2KB也会变成Non-Cacheable。所以缓冲区定义时最好按对齐要求来避免浪费地址空间。3.4 链接脚本中直接指定段属性还有一种更省事的做法在链接脚本里把DMA缓冲区放到一个专门的段然后通过MMU或MPU统一配置这个段的属性。这样代码里不用每次单独配置所有DMA缓冲区自动就是Non-Cacheable的。/* 链接脚本片段 */ .dma_buffer (NOLOAD) : ALIGN(64) { __dma_buffer_start .; *(.dma_buffer) __dma_buffer_end .; } RAM然后在C代码里用attribute把变量放到这个段__attribute__((section(.dma_buffer), aligned(64))) uint8_t dma_rx_buf[4096];对齐到Cache行大小很重要后面讲手动维护时会详细说。这里先记住64字节对齐是很多处理器的Cache行大小对齐能避免伪共享问题。注意把缓冲区设为Non-Cacheable后CPU访问性能会下降。如果这块内存既要DMA搬数据又要CPU频繁处理建议评估一下性能是否可接受不行就换后面的方案。4. 第二招手动维护Cache该清就清该无效就无效4.1 Cache维护的两个核心操作如果缓冲区必须保持Cacheable以获得性能那就得在DMA传输的关键节点手动维护Cache。核心操作就两个Clean和Invalidate。Clean是把Cache里的脏数据写回内存。什么时候用DMA要读内存之前。因为CPU可能刚写过缓冲区数据还在Cache里没落盘DMA直接读内存会读到旧值。所以要先Clean把CPU的更新推送到内存DMA才能读到新数据。Invalidate是把Cache里的对应行标记为无效。什么时候用DMA写完内存之后。因为CPU之前可能读过这块区域Cache里留着旧副本DMA的新数据写到了内存但Cache不知道。Invalidate之后CPU再读就会Cache Miss从内存重新加载新数据。这两个操作的方向千万别搞反。我见过有人DMA发送前做Invalidate结果把CPU刚写的数据给无效掉了DMA读到的是内存里的随机值。也见过DMA接收后做CleanCache里的旧数据被写回内存把DMA刚写的新数据覆盖了。这种错误很隐蔽因为不是每次都出问题取决于Cache的替换时机。4.2 按Cache行操作还是按地址范围操作Cache维护的粒度是Cache行不是单个字节。大多数处理器的Cache行是32字节或64字节。当你Invalidate一个地址时实际上整个Cache行都被无效掉了。这就带来一个问题如果两个变量恰好在同一个Cache行里你Invalidate其中一个另一个也被顺带无效了。如果另一个变量是CPU刚写过还没落盘的脏数据这一无效就丢了。所以DMA缓冲区一定要按Cache行大小对齐并且大小最好是Cache行的整数倍。这样维护时就不会误伤其他数据。#define CACHE_LINE_SIZE 64 __attribute__((aligned(CACHE_LINE_SIZE))) uint8_t dma_buf[4096]; // 大小是64的整数倍起始地址也64对齐如果缓冲区大小不是Cache行整数倍比如100字节那它占用的最后一个Cache行里可能还有别的变量。维护时要么把整个行都算进去要么把缓冲区补齐到128字节。4.3 具体API调用与参数说明不同平台提供的Cache维护API不一样但思路相通。以ARM Cortex-A系列为例常用的是__builtin___clear_cache或者平台提供的clean_dcache_range、invalidate_dcache_range。// DMA发送前Clean缓冲区确保CPU写的数据落到内存 clean_dcache_range((uintptr_t)dma_tx_buf, (uintptr_t)dma_tx_buf sizeof(dma_tx_buf)); // 启动DMA发送 start_dma_transfer(dma_tx_buf, sizeof(dma_tx_buf)); // DMA接收完成后Invalidate缓冲区丢弃Cache里的旧副本 invalidate_dcache_range((uintptr_t)dma_rx_buf, (uintptr_t)dma_rx_buf sizeof(dma_rx_buf)); // 然后CPU才能读到DMA写入的新数据 process_rx_data(dma_rx_buf);在Cortex-M7上用的是SCB相关的寄存器操作// Clean并Invalidate指定范围 SCB_CleanInvalidateDCache_by_Addr((uint32_t *)dma_buf, sizeof(dma_buf));注意这个函数同时做了Clean和Invalidate适合用在DMA接收完成后。如果只是发送前用SCB_CleanDCache_by_Addr就够了避免不必要的Invalidate。4.4 操作顺序错了会怎样两个真实翻车案例第一个案例是DMA发送场景。某开发者先Invalidate再Clean想着先把旧的清掉再写新的。结果Invalidate把CPU刚填好的发送数据给无效了Clean的时候Cache里已经没有脏数据了什么都没写回内存。DMA读到的是一堆未初始化的内存值接收端收到的全是乱码。正确顺序应该是先Clean确保数据落盘再启动DMA根本不需要Invalidate。第二个案例是DMA接收场景。某开发者在DMA接收完成后只做了Clean没做Invalidate。Clean把Cache里的旧数据写回了内存正好覆盖了DMA刚写入的新数据。CPU再读的时候Cache Hit读到的还是旧值。这个bug特别隐蔽因为Clean操作本身没报错数据看起来也写了但方向完全反了。实操心得每次写Cache维护代码时先问自己一句——现在是要让DMA看到CPU的更新还是要让CPU看到DMA的更新前者用Clean后者用Invalidate。想清楚再下手能避免大部分低级错误。5. 第三招硬件一致性互联让总线帮你搞定5.1 什么是硬件Cache一致性前两招都是软件层面的补救第三招是从硬件设计上根本解决。所谓硬件一致性互联就是在总线层面增加监听机制让Cache控制器能偷听总线上的DMA传输。当DMA要写某块内存时互联单元会检查其他Cache里有没有对应的副本有就自动无效掉或者更新。当DMA要读内存时互联单元会检查Cache里有没有更新的脏数据有就先写回内存再让DMA读。这样CPU和DMA看到的数据始终一致软件完全不用管Cache维护。代价是硬件复杂度增加芯片面积和功耗都会上升所以通常只在多核高性能处理器上才配。5.2 ACE与CCI总线的协作机制ARM生态里实现硬件一致性的关键组件是CCICache Coherent Interconnect和ACEAXI Coherency Extensions总线接口。ACE在AXI的基础上增加了监听通道支持snoop事务。CCI则负责管理多个CPU簇和加速器之间的Cache一致性。当DMA设备通过ACE接口接入CCI时它的读写请求会触发对CPU Cache的监听。如果DMA写命中某个CPU的Cache脏行CCI会让该CPU把数据写回或者直接转发给DMA。如果DMA读命中脏行同样会先处理Cache再返回数据。这套机制对软件完全透明驱动开发者只需要正常配置DMA不用插入任何Cache维护代码。但前提是DMA控制器和总线都支持ACE并且系统集成时正确连接了监听信号。5.3 配置DMA为一致性访问的实操在支持硬件一致性的平台上配置DMA走一致性路径通常涉及几个步骤。首先要在DMA控制器的寄存器中设置访问属性标记为Coherent。以某款支持ACE的DMA控制器为例// 设置DMA通道的访问属性为一致性 dma_regs-CH[ch].CR | DMA_CR_COHERENT_ACCESS; // 配置源地址和目标地址 dma_regs-CH[ch].SAR (uint32_t)src_addr; dma_regs-CH[ch].DAR (uint32_t)dst_addr; dma_regs-CH[ch].BND transfer_size;然后在设备树或ACPI表中描述DMA与CCI的连接关系确保内核在初始化时知道这条路径是一致性的。Linux内核里对应的是dma-coherent属性dma_node { compatible vendor,dma-controller; dma-coherent; ... };加上这个属性后内核的DMA映射接口会自动使用一致性路径驱动代码里就不需要再调用dma_sync_single_for_cpu之类的同步函数了。5.4 硬件方案的代价与选型建议硬件一致性虽然省心但不是没有代价。支持ACE的DMA控制器通常比普通DMA贵CCI互联也会增加芯片的功耗和面积。而且不是所有处理器都支持很多中低端芯片根本没有这个选项。选型时我的建议是如果做的是高性能计算、网络加速、多核并行处理这类场景数据吞吐量大且对延迟敏感优先选支持硬件一致性的平台软件复杂度低长期维护成本也低。如果做的是成本敏感的消费电子或工业控制数据量不大用前两招软件方案就够了没必要为用不上的硬件特性买单。另外要注意即使硬件支持一致性也不是所有内存区域都默认走一致性路径。有些平台需要显式配置地址窗口的属性把DMA缓冲区所在的区域划入一致性域。这个配置通常在启动代码或设备树里完成忘了配的话硬件一致性也不会生效。6. 三招怎么选场景对照与决策表6.1 按数据量和访问频率选三招没有绝对的好坏关键看场景。我整理了一个对照表方便你快速判断。场景特征推荐方案理由缓冲区小于4KBCPU访问不频繁Non-Cacheable配置简单性能损失可忽略缓冲区大CPU需要频繁处理手动Cache维护保持Cache性能维护点可控多核系统DMA与多核交互硬件一致性软件维护多核Cache极易出错成本敏感无ACE支持Non-Cacheable或手动维护硬件方案不可用数据吞吐量极高延迟敏感硬件一致性软件维护开销成为瓶颈6.2 按开发阶段选项目不同阶段选择也可以不同。原型验证阶段怎么快怎么来直接Non-Cacheable先把功能跑通。性能优化阶段如果发现CPU处理数据成了瓶颈再改成手动维护或者换硬件一致性方案。我个人的习惯是项目初期就用Non-Cacheable把功能调通同时把DMA缓冲区的定义和配置集中管理方便后期切换方案。如果后期需要改只动配置不改业务代码。6.3 混合使用的注意事项有些复杂系统会混合使用多种方案。比如图像处理系统里小块的元数据缓冲区用Non-Cacheable大块的图像帧缓冲用手动维护核间通信又走硬件一致性。这种混合模式不是不行但一定要把每块缓冲区的属性维护策略文档化否则时间一长自己都忘了哪块该Clean哪块该Invalidate。提示建议在代码里给每块DMA缓冲区加注释标明它的Cache策略和维护要求。比如/* Non-Cacheable, no maintenance needed */或者/* Cacheable, clean before TX, invalidate after RX */。这个习惯能帮后来接手的人省很多时间。7. 踩过的坑与排查技巧实录7.1 伪共享导致的随机崩溃前面提过Cache行对齐这里展开说一个真实踩坑经历。某项目里两个DMA缓冲区紧挨着定义一个用于发送一个用于接收都没做对齐。结果发送前Clean的时候把接收缓冲区的Cache行也Clean了而接收缓冲区里正好有DMA刚写入但CPU还没读的数据Clean操作把Cache里的旧副本写回内存覆盖了新数据。这个bug不是每次都出现取决于两个缓冲区是否落在同一个Cache行以及Clean的时机排查了整整两天。解决办法就是给每个DMA缓冲区加aligned(64)属性确保它们不会共享Cache行。如果缓冲区本身小于Cache行就在末尾补padding把它撑到Cache行大小。7.2 中断上下文中的Cache维护陷阱DMA完成中断里做Cache维护是常规操作但中断上下文有它的特殊性。有些平台的Cache维护函数会关中断或者加锁如果在中断里调用可能引发死锁或者中断延迟。我遇到过在中断里调用invalidate_dcache_range导致系统卡死的情况后来查手册发现这个函数内部会获取一个自旋锁而中断上下文里持有另一个锁形成了死锁。解决办法是用平台提供的_by_Addr版本这类函数通常是无锁的直接操作Cache寄存器。或者把Cache维护放到中断下半部或者工作队列里做避开中断上下文的限制。7.3 多核场景下的核间同步多核系统里DMA缓冲区可能被多个核心访问。这时候光维护DMA和Cache的一致性还不够核间Cache也要同步。比如核心A启动了DMA接收核心B去读数据核心B的Cache里可能有旧副本需要先Invalidate再读。更麻烦的是核间同步本身需要内存屏障。如果核心A在DMA完成后更新了一个标志位核心B轮询这个标志位没有内存屏障的话核心B可能看到标志位更新了但数据还没同步。这种问题在x86上不明显因为x86的内存模型比较强但在ARM这种弱内存模型上很容易出问题。// 核心ADMA完成后 invalidate_dcache_range(rx_buf, rx_buf size); __dsb(); // 数据同步屏障确保Invalidate完成 flag 1; __dmb(); // 数据内存屏障确保flag更新在数据之后可见 // 核心B轮询 while (!flag) ; __dmb(); // 确保读到flag后再读数据 process_data(rx_buf);7.4 常见问题速查表现象可能原因排查方向DMA读到的数据是旧值CPU写的数据还在Cache未落盘检查发送前是否CleanCPU读到的数据是旧值Cache里有旧副本未无效检查接收后是否Invalidate数据偶尔正确偶尔错误Cache行未对齐维护时误伤检查缓冲区对齐和大小中断里调用维护函数卡死函数内部有锁中断上下文死锁换无锁版本或移到下半部多核间数据不同步缺少内存屏障检查DSB/DMB使用硬件一致性未生效地址窗口未划入一致性域检查设备树和启动配置7.5 调试手段怎么确认是Cache问题怀疑是Cache不一致时怎么快速确认我常用的办法是在DMA传输前后加内存dump对比物理内存和CPU读到的值。如果物理内存里是新数据而CPU读到的是旧值基本就是Cache问题。具体操作上可以用调试器直接查看物理内存地址绕过Cache。或者临时把缓冲区改成Non-Cacheable如果问题消失那就实锤了。还可以在关键位置插入Cache维护操作看问题是否解决这也是验证手段。另外有些处理器提供了Cache维护的计数器或者性能监控单元可以统计Clean和Invalidate的次数帮助确认维护操作是否按预期执行。8. 写在最后的一点个人体会Cache一致性问题之所以让人头疼是因为它不像语法错误那样编译期就报出来也不像空指针那样稳定复现。它往往在特定时序、特定数据量、特定编译优化级别下才出现换个环境就消失了。我刚开始接触DMA时被这个问题折腾过好几个通宵后来才慢慢摸清规律。我的经验是与其出了问题再排查不如在设计阶段就把Cache策略定清楚。每块DMA缓冲区在定义的时候就明确它的属性、对齐要求、维护时机写成注释或者文档。代码review时专门检查Cache维护的顺序和范围能挡掉大部分问题。还有一点不要迷信硬件一致性万能。即使平台支持ACE也要确认DMA控制器、总线、内存控制器整条路径都配对了。我见过硬件支持但软件没配好结果一致性根本没生效的案例。该做的验证一个都不能少。最后分享一个小技巧如果实在拿不准某块缓冲区该不该做Cache维护可以先把它设为Non-Cacheable跑通功能然后再逐步改成Cacheable并加上维护操作每改一步就做一次压力测试。这样能把问题定位到具体的改动上比一上来就全用Cacheable然后到处找bug要高效得多。