LVGL 9 开启 DMA 后花屏或撕裂：刷新完成与缓存所有权怎么查

作者LIU, ZHUOHUI

区分花屏撕裂和重复帧的可见证据

同步刷新正常，开启DMA后异常，说明某个时序或存储假设被暴露出来。先用静态边框加移动色块观察：像素数值损坏、运动时出现水平断层、反复显示旧内容，应进入不同排查分支。保存短视频和固件标识，并记录问题从DMA、cache还是RAM位置变化后开始。

本文以v9.3.0接口为准，迁移背景为v8.3.11，内容是待上板验证的诊断方法。测试前列出MCU、显示接口、DMA控制器、源RAM区、cache策略与实际cache line大小。DMA无法访问的内存区域，不会因为增加cache操作而变得可达。

画出渲染传输扫描三条时间线

每块buffer都应有明确拥有者：LVGL生成像素时CPU可写；提交给传输层后，对应字节范围必须保持不变，直到硬件与驱动不再读取。面板可能在之后才扫描内部显存，因此源缓冲区可复用与画面已经显示，并非同一个时刻。

SPI面板需要按外设驱动区分源数据读完、总线事务结束和面板扫描。连续扫描framebuffer的控制器，还要确认当前扫描地址以及换帧何时真正锁存。双缓冲只有在交接正确时才允许重叠工作，并不会自动消除扫描撕裂。使用TE信号也必须满足具体面板的数据窗口与时序条件。

CPU绘制、DMA读取与面板扫描三条时间线，标明源缓冲区归还和可见更新并非同一事件。
原创时序示意，非逻辑分析仪实测。源缓冲区归还与面板可见更新可能发生在不同时刻。

验证flush完成通知的真实时刻

在提交、硬件完成与lv_display_flush_ready三个位置记录低开销时间戳或GPIO，同时记录单调递增事务编号和源地址。这样可识别“旧传输的迟到中断”，避免错误地归还当前buffer。普通完成模式下，只有驱动不再使用源数据才能通知ready。

v9.3.0头文件另有flush-wait回调契约；若采用它，应单独审查等待路径，不能机械拼接两套完成方案。下面是未编译的状态机伪码，具体中断与同步实现由平台决定。

收到flush:
    断言状态为空闲
    保存事务编号、源地址和有效范围
    按平台要求使像素对DMA可见
    状态 = 传输中
    提交DMA，失败则进入恢复路径

收到匹配的完成事件:
    确认硬件停止读取源buffer
    完成必要的总线收尾
    状态 = 空闲
    lv_display_flush_ready(display)

错误或超时:
    停止并确认硬件静止
    排除迟到事件
    恢复链路或保持明确故障状态

超时不等于DMA停止。错误路径必须确认旧地址不再被读取，才决定如何归还所有权；同一提交也不能重复通知ready。

按数据流向核对cache维护

CPU在非硬件一致、write-back缓存区产生像素，DMA随后读物理内存时，可能需要先clean脏数据。invalidate的职责不同，使用不当会丢弃CPU尚未写回的内容；指令cache操作不能替代数据cache可见性。

维护范围、屏障与先后顺序必须依据芯片官方说明。ST AN4839适用于其中覆盖的STM32F7/H7场景，不能直接推广到所有STM32、ESP32或Linux。Linux驱动应使用其DMA映射接口，而不是照搬裸机cache调用。

需要对齐时，为buffer分配独立且首尾满足cache line要求的存储。维护范围向整行扩展，可能碰到同一行中的其他数据。改用已批准的非缓存区可以缩小假设范围，但不能证明最终缓存配置正确，也不能据此随意修改MPU属性。

审查双缓冲的地址和生命周期

检查A、B确实是独立空间，异步期间持续存活，而且DMA能够访问。函数内栈数组即便在调试器中暂时看起来正常，也可能在函数返回后失效。容量、对齐和链接位置要以发布构建为准，不能只检查调试版。

现象 优先边界 下一项证据
提前ready后花屏 源buffer所有权 DMA读完之前CPU是否重新写入
仅缓存RAM失败 可见性或共享缓存行 独立对齐存储的对照
运动画面有稳定断层 面板扫描同步 TE/扫描与写入的关系
只更新一帧后停住 漏通知或错误路径 提交是否存在匹配归还
恢复后偶发异常 迟到中断 事务编号是否匹配

换帧控制器必须保留旧framebuffer，直到硬件不再扫描它；SPI则还需要正确的片选和命令/数据收尾。源内存生命周期与外设事务生命周期应分别写清。

用受控对照找出最小失败条件

固定一套可重复UI，每次只改同步/DMA、单/双buffer或一种已审查的内存策略。不要同时改变总线频率、编译优化和分配位置。记录转换次数、损坏次数、超时次数与持续时间，“跑了一阵没问题”无法形成可比较的回归结论。

在可恢复实验板上加入受控中断负载，重复覆盖跨行和跨cache line的传输。避免在关键ISR打印大量文本，诊断本身可能改变时序。候选修复前后都采集同一套事件；通过提前ready制造更高更新率属于正确性缺陷，不能作为提速证据。

交付修复证据与仍未覆盖的边界

修复交付应包含buffer地址图、状态机、硬件完成事件定义、正常与错误路径，以及证明CPU写入不覆盖未完成DMA读取的时间线。标明板卡修订、RAM区域、SDK和cache设置，未覆盖的复位、超时及扫描场景单独列出。

同步发送也异常时，先回到迁移容量与像素格式检查；正确性稳定后，再把时间戳交给显示性能测量。保留低开销诊断开关，便于现场按相同事件定义复查。

如需显示驱动诊断评估，可提供脱敏flush与完成代码、RAM map、cache配置和简短时序记录。目标是形成适用于具体平台的所有权契约；本文没有实测帧率提升或跨芯片保证。

技术依据与验证范围

官方版本依据：v9 · display · cache

类似文章