1. 从一次数据采集异常说起：DMA读到的为什么总是旧值
做嵌入式开发的朋友大概率都遇到过这种场景：CPU 明明已经把最新数据写进了内存缓冲区，DMA 控制器搬运上来的却还是上一轮的旧数据，反复检查地址、长度、通道配置都没问题，数据就是"不更新"。更让人抓狂的是，单步调试的时候一切正常，全速跑起来就出问题——这种"调试器一挂就正常"的现象，几乎就是缓存一致性问题的经典信号。
这个问题的本质，是DMA（Direct 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-Cacheable），CPU 对它的每次读写都直接落到主存，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-Cacheable，CPU 每次改描述符都要走慢速总线，效率低。更好的做法是描述符用可缓存内存 + 软件维护，数据缓冲区用 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 总线与硬件缓存一致性
前两招都是"软件或配置层面"的补救，而硬件一致性是从架构上根治。在支持ACE（AXI Coherency Extensions）或CHI总线的多核 SoC 上，DMA 控制器如果也接入一致性互联（Coherent Interconnect），那么它访问内存时会自动参与缓存一致性协议——CPU 的脏数据会被硬件自动写回，DMA 写的数据会自动无效化 CPU 的旧副本。软件完全不用管 Clean/Invalidate。
这种方案性能最好、软件最省心，但有两个前提：一是 SoC 的互联总线支持一致性，二是 DMA 控制器本身支持一致性端口。很多低成本 SoC 的 DMA 是挂在非一致性总线上的，那就用不了这招。选型阶段如果预见到大量 DMA 搬运，优先选支持硬件一致性的平台，能省掉后面一大堆调试。
5.2 用一致性 API 而不是手写维护代码
即使硬件支持一致性，软件也不能乱来。Linux 内核提供了DMA API（dma_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 写用 Clean，DMA 写用 Invalidate。
- 屏障缺失：缓存维护后是否加了 DSB？DMA 启动前是否确保维护完成？
- 共享 Cache Line：DMA 缓冲区和别的变量是否共享同一行？共享就隔离。
- 属性配置：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)起步，大小取整到行边界，这类问题再没出现过。对齐这件事，多花一分钟，省下两天调试。
