本文主要是通过迁移的思维，记录本人初次使用周立功的Aworks框架进行BSP开发
本文主要讲述在RT1052上面，MIPI显示马赛克的处理过程。
1. 硬件原理图
2. 问题现象
在汽车ACC点火之后，显示马赛克。
3. 问题排查
（1）出现问题时，通过CAN消息切换该区域的显示内容，发现可以正常显示，至少说明显示硬件电路是正常的。
（2）由于MCU是XIP运行，且数据在flash上面，猜想如果是flash数据读取异常的话，至少会出现系统取指异常的问题，但是实际上并没有，所以提除flash读取出错的可能性。
（3） 复现该问题时，每次均在图片的后半断出错，在车头位置。
（4） FAE建议关闭Cache之后，看一下现象是否还有，关闭之后该问题不再出现，但是对显示帧率影响很大。这说明本身代码流程是没有问题的。是异常因素导致。本质上还是降低软件的效率，降低flash的读写。
（5）单独对flash做大容量的读写测试，也没有问题。说明本身驱动没有关题。在qspi flash驱动下，通过flash数据手册，重新确认读写的时序及数据锁存的时候，均在正常范围内。且单独降低flash的工作时钟至60M，该问题依然存在。
（6） 由于qspi flash的运行时钟比较高120M以上的工作时钟，所以对走线及PCB的阻抗有要求，虽然硬件没有按要求做，但是无法通过软件去断定肯定是硬件问题。比较明显的区别就是做过阻抗匹配参考板的PCB，调整flash时钟的输出强度，均不会造成读写出错，但是如果板子不做阻抗匹配的PCB，在某些输出强度会有读写失败的现象。
4. 处理方法
综上处理分析：
1.如果断定是硬件问题，需要等新板子回来之后，只要在新板子上面不再出现该问题，说明是走线及阻抗问题导致。
2. 通过图片原始数据校验规避该问题。
3. 减少不必要的flash读操作，由于解压图片时，默认优先会使用jpeg进行解析，但是图片资源是Png格式，默认优先使有png格式进行解析，发现该问题不再出现。
5. 总结
本质上面flash读出错的话，主要还是flash的时钟，尤其是不稳导致。还有就是软件解析出错，但是可以性比较小。该问题待确认根本原因。