DMA读旧数据？Cache一致性三招搞定

1. 从一次数据采集异常说起：DMA读到的值为什么总是慢半拍

做嵌入式开发的朋友大概率都遇到过这种场景：传感器数据明明已经更新了，DMA搬运过来的缓冲区里却还是上一轮的老值；串口收到的数据帧已经完整了，DMA描述符指向的内存却纹丝不动。你反复检查DMA配置寄存器，通道使能了、地址设对了、传输长度也没问题，甚至用调试器单步跟踪都看不出毛病——但只要一跑全速，数据就是不对。

这个现象在带Cache的处理器上尤其常见，比如Cortex-M7、Cortex-A系列、部分RISC-V内核，以及很多带L1/L2缓存的SoC。问题的根源往往不在DMA控制器本身，而在于CPU和DMA看到的内存视图不一致。CPU访问内存时会先查Cache，命中就直接返回Cache里的数据，不会去读真正的物理内存；而DMA是绕过Cache直接访问物理内存的。两边各看各的，数据自然对不上。

我最早踩这个坑是在一个图像采集项目上，CMOS传感器通过DMA把一帧图像搬到SDRAM，CPU去读的时候发现画面总是延迟一帧，偶尔还出现撕裂。当时查了两天，最后定位到就是Cache一致性问题。后来陆续在音频流、网络包处理、高速ADC采集等场景反复遇到，才把这类问题的处理套路摸清楚。

这篇内容就围绕"DMA读旧数据"这个核心现象展开，把Cache一致性的底层逻辑讲透，然后给出三套可落地的解决方案。不管你是刚接触DMA的新手，还是被Cache问题折磨过的老手，都能从中找到可以直接抄作业的操作步骤。涉及到的平台以ARM Cortex-M7和Cortex-A系列为主，但原理对所有带Cache的架构都通用。

2. Cache与DMA的视角差异：为什么CPU和DMA会看到两份数据

2.1 从一次内存读取说起：Cache到底缓存了什么

要理解这个问题，得先搞清楚Cache的工作机制。CPU执行一条加载指令时，比如从地址0x20000000读一个字节，硬件会先拿这个地址去Cache里查。Cache是按"行"管理的，典型行大小是32字节或64字节。如果这个地址所在的行已经在Cache里（命中），CPU直接拿到数据，整个过程不碰物理内存。如果没命中，Cache控制器会从物理内存把整行搬进来，然后再返回给CPU。

关键在于，Cache里存的是物理内存的一份副本。CPU写数据时，如果采用写回策略，新数据只写到Cache行里，并把这个行标记为"脏"，物理内存暂时不更新。只有等到这行被替换出去，或者显式执行清理操作，脏数据才会写回物理内存。这就意味着，在任意时刻，物理内存里的数据可能不是最新的。

DMA控制器则完全不同。它没有Cache的概念，发起传输时直接读写物理内存地址。当DMA把新数据写入物理内存后，如果CPU的Cache里恰好缓存了这块地址的旧数据，CPU再去读就会命中旧数据，完全感知不到DMA已经更新了内存。反过来，CPU写了新数据但还在Cache里没写回，DMA去搬的时候读到的就是旧数据。

2.2 三种典型的不一致场景

实际项目中，Cache不一致主要表现为三种形态，每种的处理方式略有差异。

第一种是DMA写入、CPU读取。这是最常见的场景，比如网卡收到数据包通过DMA写入内存，CPU去解析协议栈。如果CPU之前读过这块缓冲区，Cache里存了旧内容，DMA写入新数据后CPU读到的还是旧的。表现就是数据延迟、丢包、解析出错。

第二种是CPU写入、DMA读取。典型的是发送场景，CPU准备好要发送的数据放在缓冲区，然后启动DMA去搬。如果CPU写的数据还在Cache里没落到物理内存，DMA搬走的就是旧内容。表现就是发送出去的数据不对，或者部分字段是上一次的残留。

第三种是DMA读写混合、CPU也读写。比如双向通信的环形缓冲区，描述符和payload都在同一块内存里。这种最麻烦，因为读写方向交替，稍不注意就会出现描述符状态和实际数据不匹配的情况。

2.3 为什么调试器单步时一切正常

这里有个很迷惑人的现象：用调试器单步跟踪时，数据往往是对的。原因是调试器访问内存时通常会绕过Cache，直接读物理内存，或者会触发Cache维护操作。而且单步执行时CPU速度极慢，Cache行的替换和写回有充足时间发生，很多时序相关的问题被掩盖了。所以调试器正常不代表代码没问题，一定要全速跑、反复跑才能暴露Cache一致性问题。

注意：判断是否真的是Cache问题，有个简单方法——把相关内存区域配置成非缓存（Non-cacheable）再跑一遍。如果问题消失，基本可以确认是Cache一致性导致的。这个方法后面还会详细讲。

3. 第一招：把内存区域配成Non-cacheable，从源头绕开问题

3.1 MPU/MMU的配置逻辑

最直接的办法就是让CPU访问这块内存时不走Cache。在Cortex-M系列上通过MPU（Memory Protection Unit）配置，在Cortex-A系列上通过MMU页表配置。核心思路是把DMA缓冲区所在的内存区域属性设为Non-cacheable，这样CPU每次读写都直接访问物理内存，和DMA看到的是同一份数据，自然就不存在一致性问题了。

以Cortex-M7为例，MPU的配置涉及几个关键寄存器：RBAR（基地址）、RASR（属性）。RASR里的TEX、C、B三个位组合决定内存类型。要配成Non-cacheable，通常设TEX=000、C=0、B=0，同时AP位设成允许读写，XN位根据需要设置。配置完还要调用ARM_MPU_Enable之类的函数使能MPU，并确保SCB->SHCSR里的MEMFAULTENA等位正确。

Cortex-A系列通过页表项的低位属性控制，比如用PROT_MT_NORMAL_NC或者直接设成Device内存类型。Linux下可以通过dma_alloc_coherent申请一致性内存，驱动层则常用ioremap配合特定属性。

3.2 配置Non-cacheable的实操步骤

下面以Cortex-M7的MPU配置为例，给出一个可直接参考的流程。假设DMA缓冲区在0x24000000，大小64KB。

第一步，确定区域编号。MPU通常支持8到16个区域，选一个没被占用的，比如Region 3。

第二步，计算RBAR。基地址要按区域大小对齐，64KB对齐意味着低16位为0。RBAR = 0x24000000 | (1 << 4) | 3，其中VALID位和REGION编号要置上。

第三步，配置RASR。SIZE字段填区域大小的对数减1，64KB对应2^16，所以SIZE=15。TEX=0，C=0，B=0，AP=011（全访问），XN=1（禁止执行）。

第四步，使能MPU并加载配置。调用ARM_MPU_Load或直接写寄存器，然后ARM_MPU_Enable(MPU_CTRL_PRIVDEFENA_Msk)。

// Cortex-M7 MPU配置示例 void MPU_Config_NonCacheable(void) { ARM_MPU_Disable(); // Region 3: 0x24000000, 64KB, Non-cacheable ARM_MPU_SetRegion(3, 0x24000000, ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 0, 0, 0, 0, 15, ARM_MPU_REGION_NON_CACHEABLE)); ARM_MPU_Enable(MPU_CTRL_PRIVDEFENA_Msk); }

3.3 这种方案的代价与适用边界

Non-cacheable方案最大的优点是简单、彻底，配好之后基本不用再操心一致性问题。但代价也很明显：CPU访问这块内存的速度会大幅下降。Cache的意义就是弥补CPU和内存之间的速度差，绕开Cache等于放弃了这部分性能。对于高频访问的缓冲区，比如每毫秒都要读写的音频环形缓冲，性能损失可能达到数倍。

所以这个方案适合以下场景：DMA缓冲区不大、访问频率不高、对实时性要求高于吞吐量。比如低速ADC采集、命令响应缓冲区、配置参数区。如果是高速数据流，比如摄像头raw数据、千兆网包缓冲，就不太合适，得用后面的方案。

还有一个容易忽略的点：配成Non-cacheable后，编译器可能会对访问做优化，比如把多次读合并成一次。如果这块内存会被DMA异步修改，需要加volatile修饰，或者用内存屏障指令，否则编译器优化同样会导致读到旧值。这一点和Cache无关，但现象类似，排查时容易混淆。

4. 第二招：手动维护Cache，Clean和Invalidate的时机是关键

4.1 Clean和Invalidate到底做了什么

如果不想牺牲性能，就得保留Cache，然后在DMA传输前后手动做Cache维护。这里有两个核心操作：Clean和Invalidate。

Clean的作用是把Cache里的脏数据写回物理内存。执行Clean后，Cache行变成干净状态，物理内存里是最新数据。这个操作用在CPU写完数据、DMA要去读之前。如果不做Clean，DMA读到的可能是物理内存里的旧值。

Invalidate的作用是把Cache行标记为无效。执行Invalidate后，CPU再访问这块地址会重新从物理内存加载。这个操作用在DMA写完数据、CPU要去读之前。如果不做Invalidate，CPU可能命中Cache里的旧数据。

还有一个组合操作叫Clean and Invalidate，先写回再无效，用在双向场景或者不确定数据状态的时候。

4.2 按传输方向确定维护策略

维护策略的核心原则是：谁写谁负责，写之前Clean，读之前Invalidate。具体可以分成几种情况。

DMA读（CPU写、DMA读）：CPU准备好数据后，对缓冲区执行Clean操作，然后启动DMA。这样DMA能读到最新数据。

DMA写（DMA写、CPU读）：启动DMA前对缓冲区执行Invalidate，防止CPU之前的读操作留下旧Cache行。DMA传输完成后，再执行一次Invalidate，确保CPU读到新数据。注意这里启动前的Invalidate容易被忽略，如果缓冲区之前被CPU读过，Cache里有旧行，DMA写入后这些行不会自动失效，CPU还是会读到旧值。

双向传输：传输前Clean，传输后Invalidate。如果同一块缓冲区既读又写，可能需要Clean and Invalidate。

4.3 按地址范围操作的API与注意事项

ARM提供了CMSIS标准接口来操作Cache，Cortex-M7上常用的是SCB_CleanDCache_by_Addr、SCB_InvalidateDCache_by_Addr、SCB_CleanInvalidateDCache_by_Addr。这些函数接受地址和长度参数，内部会按Cache行对齐处理。

// DMA发送前：Clean数据缓存 SCB_CleanDCache_by_Addr((uint32_t*)tx_buffer, TX_LEN); // 启动DMA发送 DMA_Start(tx_buffer, TX_LEN); // DMA接收完成后：Invalidate数据缓存 SCB_InvalidateDCache_by_Addr((uint32_t*)rx_buffer, RX_LEN); // 此时CPU读取rx_buffer能拿到最新数据

这里有几个坑必须注意。第一，地址和长度最好按Cache行对齐。如果起始地址没对齐，函数内部会处理，但可能影响到相邻数据。如果长度不是行大小的整数倍，末尾可能多无效化几个字节，如果这些字节恰好是别的变量，就会导致意外。稳妥做法是把缓冲区按行大小对齐，长度也取整。

第二，Invalidate操作会丢弃未写回的数据。如果缓冲区里有CPU刚写但还没Clean的数据，直接Invalidate会把这些数据丢掉。所以Invalidate之前要确认没有脏数据，或者用Clean and Invalidate。

第三，多核场景下更复杂。如果多个核共享内存，还要考虑核间Cache一致性，可能需要用硬件一致性协议或者核间中断配合维护操作。这个超出了单核讨论范围，但心里要有数。

4.4 一个真实的排查案例

之前有个项目，音频播放偶尔出现"咔哒"声，概率大概百分之一。查了很久，最后定位到是DMA描述符的Cache维护有问题。描述符区是CPU写、DMA读，代码里只对payload做了Clean，忘了对描述符做Clean。大部分时候描述符恰好被Cache替换出去了，物理内存是新的，所以正常；偶尔描述符还在Cache里没写回，DMA读到旧描述符，就出现异常。加上描述符的Clean后问题消失。

这个案例说明，Cache维护要覆盖所有DMA访问的内存，包括数据区和描述符区，不能只盯着payload。而且这类问题往往是概率性的，压力测试和长时间运行才能暴露。

5. 第三招：用一致性内存分配，让硬件和软件各司其职

5.1 什么是Cache一致性内存

前两招一个是绕开Cache，一个是手动维护Cache，都属于"软件层面打补丁"。第三招是从内存分配层面解决，直接申请一块硬件保证一致性的内存。在带硬件Cache一致性单元的SoC上，比如很多Cortex-A多核芯片，有专门的CCI（Cache Coherent Interconnect）或类似模块，能自动维护CPU Cache和DMA之间的一致性，软件不需要手动Clean/Invalidate。

在Linux环境下，dma_alloc_coherent就是干这个的，它返回的内存在CPU和设备看来是一致的。在裸机或RTOS环境下，如果SoC支持，也可以通过配置特定内存区域的属性来实现，比如把某块SRAM配成硬件一致性区域。

5.2 一致性内存的申请与使用

Linux驱动里申请一致性内存的典型写法：

// 申请一致性DMA内存 dma_addr_t dma_handle; void *cpu_addr = dma_alloc_coherent(dev, size, &dma_handle, GFP_KERNEL); if (!cpu_addr) { // 处理申请失败 } // cpu_addr给CPU用，dma_handle给设备用 // 使用完毕后释放 dma_free_coherent(dev, size, cpu_addr, dma_handle);

裸机环境下，如果SoC有TCM（Tightly Coupled Memory）或者特定的一致性SRAM，把DMA缓冲区放在那里也能达到类似效果。TCM通常不经过Cache，访问速度快，是DMA缓冲区的理想位置。但TCM容量有限，一般几十到几百KB，要省着用。

5.3 三种方案的选型对比

到底用哪种方案，不能拍脑袋，得结合具体场景。下面这张表把三种方案的关键维度列出来，方便对照。

选型的基本思路是：如果SoC支持硬件一致性，优先用一致性内存，省心；如果不支持，缓冲区小且访问不频繁，用Non-cacheable；如果缓冲区大、吞吐量高，用手动维护，但要非常小心时机。

5.4 混合使用的实际案例

实际项目里往往不是单一方案，而是混合使用。比如一个视频处理系统，摄像头raw数据用DMA搬到一块大缓冲区，这块用手动Cache维护保证吞吐；而DMA描述符和状态寄存器放在Non-cacheable区域，避免频繁维护；系统级的共享内存用一致性内存分配。这样各取所长，既保证性能又降低出错概率。

混合使用的关键是把内存分区规划清楚，哪块用什么策略，在链接脚本或MPU配置里明确下来，并且写进文档。否则时间一长，接手的人根本不知道某块内存为什么这么配，改错一处就出问题。

6. 排查Cache一致性问题的完整链路

6.1 从现象到根因的定位步骤

遇到DMA数据不对，不要一上来就怀疑Cache，先按顺序排除其他可能。第一步，确认DMA配置本身没问题：通道、地址、长度、触发源、优先级。第二步，确认数据确实被DMA搬到了物理内存，可以用调试器直接看物理地址，或者用一块Non-cacheable的临时缓冲区做对比。第三步，如果物理内存数据是对的但CPU读出来不对，基本就是Cache问题。

定位到Cache问题后，再细分方向：是DMA写CPU读，还是CPU写DMA读，还是双向。然后检查对应的维护操作有没有做、时机对不对、地址范围对不对。可以用一个简单实验验证：在读取前手动加一句Invalidate，如果数据对了，说明就是缺Invalidate。

6.2 几个高频踩坑点

第一个坑是只维护了数据区，忘了描述符区。前面案例讲过，描述符也是DMA访问的内存，同样需要维护。

第二个坑是维护操作的地址没对齐。Cache行是32或64字节，如果缓冲区起始地址没对齐，维护操作可能影响到相邻变量，导致莫名其妙的错误。

第三个坑是在中断里做大量Cache维护。Cache维护操作本身有开销，如果在高频中断里对大数据块做Clean/Invalidate，会严重影响实时性。解决办法是把维护操作移到任务上下文，或者减小维护粒度。

第四个坑是编译器优化导致的假象。前面提过，Non-cacheable内存如果不加volatile，编译器可能优化掉重复读取。这类问题和Cache无关，但现象一样，排查时要一起考虑。

6.3 用工具辅助验证

如果条件允许，用逻辑分析仪或者Trace工具抓DMA总线和CPU总线的访问，能直观看到两者访问的地址和数据。有些高端调试器支持Cache命中率统计，也能帮助判断。软件层面，可以在关键位置打时间戳，对比DMA完成时间和CPU读到新数据的时间差，如果时间差明显，说明中间有Cache延迟。

还有一个土办法但很有效：把缓冲区内容填充成特定模式（比如0xAA），启动DMA后看CPU读到的是0xAA还是新数据。如果是0xAA，说明CPU读的是Cache里的旧值，DMA的新数据没被看到。这个方法简单直接，适合快速验证。

7. 一些实战中的经验补充

关于Cache行大小，不同芯片不一样，Cortex-M7通常是32字节，Cortex-A系列常见64字节。写代码时不要硬编码行大小，用CMSIS提供的宏或者从系统寄存器读，否则换芯片就出问题。

关于DMA突发长度和Cache行的关系，如果DMA突发长度小于Cache行，可能出现部分行更新的情况，维护时要注意覆盖完整行。稳妥做法是让DMA传输按Cache行对齐，长度取整。

关于多缓冲区轮转，比如双缓冲或环形缓冲，每块缓冲区的维护要独立做，不能只维护当前块。切换缓冲区时，新块的状态要确认清楚，是Clean还是Invalidate还是都要做。

关于测试，Cache一致性问题往往在特定时序下才出现，单元测试很难覆盖。建议做长时间压力测试，比如连续跑几小时，同时用不同数据模式（全0、全1、随机、递增）交叉验证。有条件的话做温度循环测试，因为Cache行为可能受温度影响。

最后说个心态问题。Cache一致性问题是嵌入式开发里比较"玄学"的一类，有时候改一行代码就好了，但不知道为什么好；有时候看起来没问题，跑一会儿又出。遇到这类问题不要慌，按"确认现象、定位方向、验证假设、修复回归"的流程走，配合前面说的排查链路，基本都能搞定。关键是理解CPU和DMA看到的是两份数据这个本质，剩下的就是时机和范围的问题。