RootCause深度分析：为什么DCache常会导致LCD显示异常（数据一致性问题）

问题描述：

很多具备Dcache的 LCD显示设备，在MCU程序设计中，经常会发生由于使用DCache引起的数据错误/混乱等问题，导致LCD显示异常，例如出现花屏、页面显示错位、屏幕显示失真等现象。

这都是属于数据一致性问题：

既Cache与外部存储中的数据不一致，会导致core（软件）与硬件模块（例如PXP, eLCDIF）之间配合失败，也会导致不同软件函数间协调失败（比如需要判断flag的）。

接下来深度分析一下，从根本上理解，才能今后尽量规避这类issue~

L1/L2 Cache简介

以ARM Cortex-M7 举例：

• L1，L2 Cache指的都是CPU的缓存，也叫一级/二级缓存，他们比内存快，但是很昂贵，所以用作缓存
• CPU查找数据的时候首先在L1，然后看L2，找到数据了就叫命中，如果都没找到（未命中），再去访问内存

Cortex-M7 架构图如下：

问题分析：

数据不一致问题是一个比较常见的嵌入式开发issue，因为外部设备memory操作（如HyperRAM、Flash、DMA）对于CPU来说也是不透明的，外部设备操作导致内存中数据更新，对于CPU来说是完全不可见的。反之亦然，CPU写入数据到缓冲区，其实是写到了cache，还未写入到外部memory （既cache和外部memory数据不一致）

而在我们的案例中，RootCause正是由于HyperRam与Cache的数据不一致，导致MCU更新LCD 的Framebuffer有误，产生LCD显示异常现象。

再细节一点，就是由于HyperRAM速率和LCD刷新频率不协调，并且由于硬件原因，这两个速率可调整的范围较小，无法完美融合，这些问题导致Framebuffer数据更新不及时，既导致cache中的数据不能及时被更新到HyperRAM，既Framebuffer 数据不能正常更新，发生LCD显示页面花屏、错位等。

这里的数据流是：页面显示过程中，MCU将要变更的Framebuffer数据先写到Cache，然后通过cache 写入到对应HyperRAM地址，而LCD引擎只通过获取HyperRAM里的Framebuffer某一起始地址数据进行显示

问题解决：

因为我们项目中使用GUI lib 是Embedded Wizard（EW），RAM扩展了HyperRAM，所以在代码编程角度，有以下解决思路：

1. EW刷新UI后， clean 一次 Dcache，强制使其保持数据一致性
2. 将LCD Buffer中DMA操作的数据设置成NonCacheble的
3. 将Dcache关掉

实际应用中，由于第3条关掉Dcache后，我们的LCD显示和操作都会变很慢，所以不能使用

所以最终使用了1、2两种方案结合解决该问题：

如何编程：

在刷新UI页面时，保持Dcache数据一致性可以通过调用Cache 提供的功能性API Lib。
例如在NXP平台，可以调动如下API：

Invalide

首先是Invalide, 强制使cache中的内容无效（相当于invalidate会丢弃cache里的数据，下面会介绍原理）

可以调用：

• L1CACHE_InvalidateDCacheByRange()

注意Invalidate操作的地址需要 32-byte对齐

• 在EW每次Fill data时将Dcache对应内容先Invalid，在End时候做Clean，保持一致性:

L1CACHE_InvalidateDCacheByRange()里其实调用的的SCB_InvalidateDCache_by_Addr()

完整调用栈如下：

Clean

Clean操作会将cache中尚未写入到主存中的数据强制写到主存（既将cache和外部存储数据刷新一次， 下面会介绍原理）

通过调用：

• L1CACHE_CleanDCacheByRange()

完整调用栈如下：

HyperRAM：

因为我们项目还用到了HyperRam，所以在读取HyperRam上的Frambuffer更新到LCD后，也需要将这段存放数据的内存进行clean cache操作：

Cache clean/invalidate 操作原理

ARM Cache官方文档标注如下：

通过以上说明，可以得出结论：

• clean：将cache中尚未写入到主存中的数据强制写到主存。（可以重建cache与主存之间的一致性，写入后会把cache中的Dirty flag清零）

• invalidate：== flush，将cache中的invalid标志位设置为1/0，使本cache中的内容无效。（相当于invalidate会丢弃cache里的数据。）

如下描述

实际代码调用栈示例：

LCD显示异常常见原因

LCD图像位移

LCD显示在水平方向发生位移，或者在上面或底部有一条几个像素的彩色、白色或黑色条纹。一般来说，出现这种情况，都是因为初始化参数设置不对，和行同步或者场同步信号有关。

显示位置有位移或者错位，就检查LCD模组和CPU上的LCD控制器的行同步与场同步信号的宽度、前后延时、极性的匹配。最可能的就是回扫的前后延时时间不匹配。

另外，这种情况通常错位不会很多，如果出现错位了一半的图像之类的情况，通常就是别的原因造成的了。而且有时候，有的LCD的行信号、场信号的设置还和LCD驱动芯片的部分电压参数的取值设置有关。

LCD图片错位、叠加、重复常见原因

LCD显示上大范围的图像出现错位、叠加或者重复，出现这种情况一般不会是行同步或者场同步信号的延时引起的，基本可以排除这方面的影响。

可以检查下抽样等功能的参数是否正常，还有就是因为LCD的硬件平台不同，而在时序或者时钟频率上存在差异引起的。碰见这种情况首先应该做的就是先仔细计算DMA传输参数。其它的情况要具体问题具体分析。

---

博主热门文章推荐：

一篇读懂系列：

• 一篇读懂无线充电技术（附方案选型及原理分析）
• 一篇读懂：Android/iOS手机如何通过音频接口（耳机孔）与外设通信
• 一篇读懂：Android手机如何通过USB接口与外设通信（附原理分析及方案选型）

LoRa Mesh系列：

• LoRa学习：LoRa关键参数（扩频因子，编码率，带宽）的设定及解释
• LoRa学习：信道占用检测原理（CAD）
• LoRa/FSK 无线频谱波形分析（频谱分析仪测试LoRa/FSK带宽、功率、频率误差等）

网络安全系列：

• ATECC508A芯片开发笔记（一）：初识加密芯片
• SHA/HMAC/AES-CBC/CTR 算法执行效率及RAM消耗 测试结果
• 常见加密/签名/哈希算法性能比较 (多平台 AES/DES, DH, ECDSA, RSA等)
• AES加解密效率测试（纯软件AES128/256）–以嵌入式Cortex-M0与M3 平台为例

嵌入式开发系列：

• 嵌入式学习中较好的练手项目和课题整理（附代码资料、学习视频和嵌入式学习规划）
• IAR调试使用技巧汇总：数据断点、CallStack、设置堆栈、查看栈使用和栈深度、Memory、Set Next Statement等
• Linux内核编译配置（Menuconfig）、制作文件系统 详细步骤
• Android底层调用C代码（JNI实现）
• 树莓派到手第一步：上电启动、安装中文字体、虚拟键盘、开启SSH等
• Android/Linux设备有线&无线 双网共存（同时上内、外网）

AI / 机器学习系列：

• AI: 机器学习必须懂的几个术语：Lable、Feature、Model…
• AI：卷积神经网络CNN 解决过拟合的方法 （Overcome Overfitting）
• AI: 什么是机器学习的数据清洗（Data Cleaning）
• AI: 机器学习的模型是如何训练的？（在试错中学习）
• 数据可视化：TensorboardX安装及使用（安装测试+实例演示）

---