1. 从一次数据采集异常说起DMA读到的为什么总是旧值做嵌入式开发的朋友大概率都遇到过这种场景CPU 明明已经把最新数据写进了内存缓冲区DMA 控制器搬运上来的却还是上一轮的旧数据反复检查地址、长度、通道配置都没问题数据就是不更新。更让人抓狂的是单步调试的时候一切正常全速跑起来就出问题——这种调试器一挂就正常的现象几乎就是缓存一致性问题的经典信号。这个问题的本质是DMADirect Memory Access直接内存访问与CPU Cache高速缓存之间的可见性冲突。CPU 写数据时为了性能写操作往往先落在 Cache 里并没有立刻同步到主存DDR/SRAM而 DMA 控制器是独立于 CPU 的外设它访问的是物理内存看不到 Cache 里的内容。于是 CPU 以为我写好了DMA 却从主存里搬走了旧数据。反过来DMA 把新数据写进主存CPU 读的时候如果 Cache 里还留着旧副本读到的也是旧值。这个坑在带 Cache 的处理器上几乎无法回避——ARM Cortex-A 系列、部分 Cortex-M7、RISC-V 带缓存的应用级核心、以及各类 SoC 上的异构核只要涉及 DMA 搬运就一定会撞上。它不分平台、不分厂商是体系结构层面的固有问题。本文就围绕这个核心矛盾把为什么会出现怎么定位三招怎么用讲透让你下次遇到 DMA 读旧数据时能直接对症下药。需要先明确一点本文讨论的是带数据缓存D-Cache的处理器场景。如果你的芯片根本没有 Cache比如很多 Cortex-M3/M4 裸机项目那基本不会遇到这个问题DMA 和 CPU 看到的都是同一份物理内存。但只要你的平台有 D-Cache且 DMA 缓冲区是普通可缓存内存这个坑就埋在那里了。2. 缓存一致性的底层逻辑CPU、Cache、DMA 三者的数据视角2.1 为什么 CPU 写的数据 DMA 看不见要理解这个问题得先搞清楚现代处理器访问内存的层级结构。CPU 核心访问数据时走的路径是CPU → L1 D-Cache → L2 Cache → 主存。当 CPU 执行一条存储指令比如STR时数据首先被写入 D-Cache 行Cache Line此时这条 Cache Line 被标记为脏Dirty。至于什么时候真正写回主存取决于缓存策略写回Write-Back脏行一直留在 Cache 里直到被替换出去或者被显式清理时才写回主存。这是绝大多数高性能处理器的默认策略也是问题的根源。写通Write-Through每次写都同步更新主存。这种策略下 DMA 能看到最新数据但性能损失明显实际很少用。在写回策略下CPU 写完数据后主存里还是旧值而 DMA 恰恰只认主存。这就是DMA 读旧数据最直接的原因。2.2 DMA 写回的数据 CPU 为什么读不到反过来同样成立。DMA 把外设数据搬到内存缓冲区后主存更新了但 CPU 的 D-Cache 里可能还缓存着这块缓冲区之前的旧内容。CPU 去读的时候Cache 命中直接返回旧副本根本不会去主存取新数据。这时候你会看到DMA 明明搬完了CPU 读出来还是老样子。这里有个容易被忽略的细节Cache Line 的粒度问题。Cache 操作的最小单位是一整行常见 32 字节或 64 字节而不是单个字节。这意味着即使你只想同步 4 个字节实际操作也会影响整行。如果 DMA 缓冲区和别的变量共享同一行 Cache清理或无效化时就会误伤邻居数据这是后面要重点讲的坑。2.3 一致性问题的两种典型触发路径把上面的分析归纳一下DMA 与 Cache 的冲突有两条清晰的路径方向CPU 侧动作DMA 侧动作现象CPU 写 → DMA 读数据留在 D-Cache主存未更新从主存读取DMA 读到旧数据DMA 写 → CPU 读Cache 里留有旧副本写入主存CPU 读到旧数据两条路径的解决思路是相反的前者需要在 DMA 启动前把 CPU 的脏数据推到主存Clean/Flush后者需要在 DMA 完成后把 CPU 的旧副本作废Invalidate。搞混这两个方向是新手最常犯的错误——用 Invalidate 去解决 CPU 写的问题结果把还没写回的数据直接丢掉数据损坏得更彻底。注意Clean 和 Invalidate 是两个方向相反的操作Clean 是把 Cache 写回主存Invalidate 是把 Cache 标记为无效、下次强制从主存读。用错方向比不处理还危险。3. 第一招软件维护缓存——Clean 与 Invalidate 的正确用法3.1 按数据流向选择操作而不是凭感觉软件维护缓存是最通用、最不依赖硬件配置的方案核心就一句话根据数据流向决定 Clean 还是 Invalidate。CPU 写、DMA 读发送方向DMA 启动前对缓冲区执行Clean也叫 Flush把 CPU 的脏数据写回主存保证 DMA 读到最新值。DMA 写、CPU 读接收方向DMA 完成后对缓冲区执行Invalidate丢弃 CPU 侧的旧副本强制下次从主存读新数据。如果是双向缓冲区比如既要 CPU 填一部分、又要 DMA 填一部分那就要在启动前 Clean、完成后 Invalidate两步都做。在 ARM 平台上对应的操作通常是clean_dcache_range(addr, size)和invalidate_dcache_range(addr, size)或者用 CMSIS 里的SCB_CleanDCache_by_Addr()/SCB_InvalidateDCache_by_Addr()。RISC-V 平台则通过fence指令配合自定义的缓存操作指令实现。不管哪个平台逻辑是一致的。3.2 地址和长度必须按 Cache Line 对齐这是软件维护缓存最容易踩的坑。前面说过Cache 操作以行为单位如果你传入的地址不是行对齐的硬件通常会向下对齐到行首长度也会向上取整到行边界。结果就是你只想 Invalidate 自己那 100 字节的缓冲区实际却把相邻的、CPU 正在用的变量所在的行也无效化了。如果那个变量恰好是脏数据还没写回直接丢失程序跑飞。你只想 Clean 自己的缓冲区实际把邻居的脏行也一起写回了虽然一般不会出错但可能引入不必要的总线流量。正确的做法是DMA 缓冲区必须按 Cache Line 大小对齐且大小是 Cache Line 的整数倍。Cache Line 大小因平台而异Cortex-A9 常见 32 字节Cortex-A53/A72 常见 64 字节具体查芯片手册或读CTR_EL0寄存器确认。// 假设 Cache Line 为 64 字节 #define CACHE_LINE_SIZE 64 // 缓冲区按行对齐大小取整到行边界 static uint8_t dma_buf[1024] __attribute__((aligned(CACHE_LINE_SIZE))); void dma_send_prepare(void *buf, size_t len) { // 长度向上取整到 Cache Line 边界 size_t aligned_len (len CACHE_LINE_SIZE - 1) ~(CACHE_LINE_SIZE - 1); clean_dcache_range((uintptr_t)buf, aligned_len); // 之后才启动 DMA }3.3 一个真实踩坑Invalidate 把未写回的数据清掉了我见过一个很典型的案例某采集系统里CPU 先往缓冲区头部写了一个状态标志然后启动 DMA 接收数据到缓冲区尾部DMA 完成后对整个缓冲区做 Invalidate。结果状态标志偶尔会变成随机值。原因就是——CPU 写的状态标志还在 Cache 里没写回Invalidate 直接把这一行作废了主存里那个位置还是旧的随机内容CPU 再读就拿到了垃圾值。修复方法很简单在 Invalidate 之前先对 CPU 写过的那部分做 Clean或者干脆把状态标志和 DMA 数据区分到不同的 Cache Line 里避免相互干扰。这个案例说明软件维护缓存不是无脑调 API必须清楚每一块内存的读写归属。4. 第二招把缓冲区划成不可缓存内存从源头绕开冲突4.1 Non-Cacheable 内存的适用场景与代价如果一块内存被配置为不可缓存Non-CacheableCPU 对它的每次读写都直接落到主存Cache 里不留副本那么 DMA 和 CPU 看到的永远是同一份数据一致性问题自然消失。这是最省心的方案配置一次之后完全不用管 Clean/Invalidate。配置方式通常有两种通过 MMU 页表属性在页表项里把该区域的 memory attribute 设为 Non-Cacheable比如 ARM 的Normal Non-Cacheable或Device属性。这是最彻底的方式适用于大块专用缓冲区。通过 MPU 区域配置在带 MPU 的处理器上把某段地址范围划为 Non-Cacheable。适合没有 MMU 但有 MPU 的平台。代价也很明显CPU 访问这块内存会变慢。每次读写都要走总线到主存延迟可能是 Cache 命中的几十倍。所以 Non-Cacheable 只适合那些CPU 访问频率低、但 DMA 频繁搬运的缓冲区比如网卡收发包描述符、大块传感器数据缓冲。如果 CPU 要频繁读写这块数据性能会明显下降。4.2 描述符和缓冲区要分开对待一个实用的经验是把 DMA 描述符Descriptor和实际数据缓冲区区别对待。描述符是 CPU 和 DMA 都要频繁访问的小结构如果整个划成 Non-CacheableCPU 每次改描述符都要走慢速总线效率低。更好的做法是描述符用可缓存内存 软件维护数据缓冲区用 Non-Cacheable。或者反过来看哪边访问更频繁。还有一种折中方案Write-Through 缓存属性。它让 CPU 写操作同时更新 Cache 和主存DMA 能看到最新数据但 CPU 读还是走 Cache 加速。缺点是每次写都有总线开销适合写少读多的场景。4.3 配置 Non-Cacheable 时最容易忽略的对齐问题即使划成 Non-Cacheable内存区域的起始地址和大小仍然建议按 Cache Line 对齐。原因是MMU/MPU 的区域划分如果和 Cache Line 边界不对齐可能出现同一行 Cache 里既有可缓存部分又有不可缓存部分的情况硬件行为会变得难以预测有些平台甚至会直接报错或静默降级。所以配置时老老实实按行对齐别图省事。另外配置 Non-Cacheable 后要记得刷新一次 TLB 或重配 MPU否则旧的缓存属性可能还在生效。这个细节在动态修改内存属性的场景里特别容易漏。5. 第三招硬件一致性——让总线帮你搞定5.1 ACE/CHI 总线与硬件缓存一致性前两招都是软件或配置层面的补救而硬件一致性是从架构上根治。在支持ACEAXI Coherency Extensions或CHI总线的多核 SoC 上DMA 控制器如果也接入一致性互联Coherent Interconnect那么它访问内存时会自动参与缓存一致性协议——CPU 的脏数据会被硬件自动写回DMA 写的数据会自动无效化 CPU 的旧副本。软件完全不用管 Clean/Invalidate。这种方案性能最好、软件最省心但有两个前提一是 SoC 的互联总线支持一致性二是 DMA 控制器本身支持一致性端口。很多低成本 SoC 的 DMA 是挂在非一致性总线上的那就用不了这招。选型阶段如果预见到大量 DMA 搬运优先选支持硬件一致性的平台能省掉后面一大堆调试。5.2 用一致性 API 而不是手写维护代码即使硬件支持一致性软件也不能乱来。Linux 内核提供了DMA APIdma_map_single、dma_unmap_single、dma_sync_single_for_cpu/device等这些 API 会根据平台是否硬件一致自动选择空操作还是软件维护。也就是说写驱动时统一用 DMA API不要手写 Clean/Invalidate这样代码在一致性和非一致性平台上都能正确工作移植性最好。裸机开发没有这套 API那就得自己封装一层根据平台宏决定是调用缓存维护函数还是空操作。封装好之后上层业务代码不用关心底层差异。5.3 三种方案的选型对照把三招放在一起对比方便你按项目实际情况选方案适用场景性能影响实现复杂度主要风险软件维护 Clean/Invalidate通用任何带 Cache 平台中每次搬运有维护开销中需处理对齐和方向方向搞反、对齐错误导致数据损坏Non-Cacheable 内存CPU 访问少的专用缓冲区高CPU 访问变慢低配置一次区域对齐、属性配置遗漏硬件一致性支持 ACE/CHI 的 SoC低硬件自动处理低用标准 API平台不支持则无法使用实际项目里往往是组合使用描述符用软件维护大数据缓冲区用 Non-Cacheable如果平台支持一致性就优先走硬件路径。没有银弹看场景下菜。6. 排查 DMA 读旧数据的完整链路6.1 先确认问题到底出在哪一侧遇到数据不对别急着改代码先做定位。第一步是确认数据流方向是 CPU 写、DMA 读出的值旧还是 DMA 写、CPU 读出的值旧这决定了你要 Clean 还是 Invalidate。判断方法很简单在 DMA 启动前后、完成前后分别打印主存原始值用 Non-Cacheable 的调试串口或者直接读物理地址对比 Cache 侧读到的值就能看出是哪一侧没同步。第二步是确认缓冲区是否真的可缓存。有些平台默认把某段地址划为 Non-Cacheable你以为有 Cache 问题其实是别的原因。查页表属性或 MPU 配置确认。6.2 用调试器验证缓存行为前面提到单步调试正常、全速跑出错这本身就是强信号。因为调试器读写内存时往往会触发缓存维护或者调试器走的是非缓存路径掩盖了问题。所以不要依赖调试器判断缓存问题要用运行时打印、GPIO 翻转、或者专门的缓存状态寄存器来验证。一个实用技巧在关键位置插入DSB数据同步屏障和ISB指令同步屏障指令确保缓存维护操作真正完成后再启动 DMA。缓存维护指令是异步的不加屏障可能出现维护指令还没执行完DMA 就启动了的竞态。6.3 常见误判与排除清单排查时按这个清单逐项过能省不少时间地址对齐缓冲区起始地址和长度是否按 Cache Line 对齐不对齐先改对齐。操作方向Clean 和 Invalidate 是否用反了CPU 写用 CleanDMA 写用 Invalidate。屏障缺失缓存维护后是否加了 DSBDMA 启动前是否确保维护完成共享 Cache LineDMA 缓冲区和别的变量是否共享同一行共享就隔离。属性配置Non-Cacheable 区域是否真的生效TLB 是否刷新DMA 控制器缓存有些 DMA 控制器自己也有写缓冲需要读回或屏障才能保证顺序。提示如果排查半天没头绪先把 DMA 缓冲区临时改成 Non-Cacheable 试一下。如果问题消失基本可以确认是缓存一致性问题再回头用软件维护方案优化性能。7. 几个只有踩过才懂的实操细节第一个细节是双向缓冲区的处理顺序。有些场景 CPU 先填头部、DMA 填尾部完成后 CPU 又要读全部。这时候正确顺序是启动前 Clean 头部CPU 写的部分完成后 Invalidate 尾部DMA 写的部分千万别对整个缓冲区无脑 Invalidate否则头部的脏数据会被丢掉。分区域处理虽然麻烦但能避免数据损坏。第二个细节是中断上下文里的缓存维护。DMA 完成中断里做 Invalidate 是常见操作但中断上下文对执行时间敏感大块缓冲区的 Invalidate 可能耗时较长影响实时性。如果缓冲区很大考虑用 Non-Cacheable 或者拆分处理别在中断里做重活。第三个细节是多核场景下的额外一层一致性。如果 CPU0 写数据、CPU1 启动 DMA那不仅要处理 Cache 和 DMA 的一致性还要处理两个 CPU 核之间的 Cache 一致性。这时候光靠 Clean/Invalidate 不够还需要核间同步机制配合。多核项目里这个问题更隐蔽建议一开始就把缓冲区归属规划清楚避免跨核共享可缓存缓冲区。最后一个经验把缓存维护封装成平台抽象层。不同芯片的 Cache Line 大小、维护指令、API 都不一样如果业务代码里到处散落clean_dcache_range移植时会很痛苦。封装成dma_sync_for_device()/dma_sync_for_cpu()这样的接口底层按平台实现上层代码一行不用改。这个习惯在项目跨平台时能救命。我在实际项目里踩过最深的坑就是一开始没重视 Cache Line 对齐缓冲区随便定义结果 Invalidate 时把相邻的全局变量清成了随机值查了两天才定位到。后来养成习惯所有 DMA 缓冲区一律aligned(64)起步大小取整到行边界这类问题再没出现过。对齐这件事多花一分钟省下两天调试。
