嵌入式DMA为何写脏？缓存怎么同步？

链路吞吐一上来，最难查的往往不是带宽不足，而是数据明明搬完了却仍然不对。嵌入式平台只要同时启用 DMA 和 Cache，缓冲区所有权与同步时机没管住，内存里看到的就会是一份被不同主机各自相信的旧数据。

所谓 DMA 写脏，很多时候不是外设真的写错，而是 CPU 仍然抓着自己缓存里的旧副本。接收路径里，DMA 已经把新样本灌进 SRAM，应用线程却从未失效 Cache，于是继续读到上一帧；发送路径里，任务先改了待发缓冲，但脏行还停在 D-Cache，DMA 启动时拿走的还是老内容。问题之所以隐蔽，在于它并不每次都出现：缓冲区是否按行对齐、相邻变量是否共享同一缓存行、后台是否碰巧发生过驱逐，都会改变结果，所以现场看起来像偶发串包，根子却在所有权没有明确交接。

更稳妥的处理方式，是把每块 DMA 缓冲都当成会在不同主机之间转手的资源。缓冲一旦交给 DMA，CPU 就不该继续随手读写；DMA 完成前只看状态位，不碰数据本体；完成后再按方向执行失效或回写，然后把所有权交还上层。这样做的价值不只是规避 bug，还能迫使接口边界清晰起来。谁负责填充，谁负责启动，谁负责消费，都有明确时刻，而不是靠“通常没事”的经验默契维持。

同步时机则比同步动作更容易写反。接收路径要在 DMA 完成后失效，若提前失效，CPU 后续读取仍可能把旧行重新拉进来；发送路径要在 DMA 启动前回写，若等外设读完再清理，晚到的正确数据也无法追回。嵌入式工程里不少“偶发前几个字节对、后面错”的现象，本质上都是时序问题，不是接口协议问题。尤其在描述符环和双缓冲结构里，一次错误的同步顺序会沿着多个缓冲轮转，很像链路某处存在幽灵比特翻转。

如果平台允许划出非缓存一致区，也不能因此放弃边界设计。非缓存区能减少维护动作，却会牺牲 CPU 访问效率；全部放进去，算法线程和日志线程又会在低速内存上吃亏。更平衡的办法通常是把高吞吐、短生命周期、只被 DMA 触达的块放到非缓存区，而把需要频繁 CPU 计算的控制结构留在缓存区，并通过对齐和独占缓存行减少相互污染。若描述符和数据缓冲共用缓存行，一次维护动作还可能误伤邻近控制字。这样既保住带宽，又不会把系统整体拖慢。

排查时最好同时抓软件事件和总线事件。记录描述符翻转、缓存维护、DMA 完成中断与应用消费时间点，再配合对齐检查和缓冲填充花纹，很快就能看出问题是出在所有权交接、同步顺序还是缓存行共享。很多人一开始怀疑外设不稳定，最后却发现错误只在某种编译优化和某个缓冲长度下出现，这恰恰说明一致性模型从来没有被明确定义。

因此，DMA 能不能真正减负，关键不在于搬得多快，而在于谁在什么时刻拥有那块内存。所有权先说清，再让缓存动作跟着方向走，数据链才会稳定。