Debug笔记-1

Freertos系统使用Curl库下载网络文件，存储到TF卡中发现部分数据错误？

整个数据链路比较长，如果没有方向需要定位具体在哪个步骤出现错误（curl下载 + 内存缓存 + glibc + 文件系统 + SD驱动读写）
- 对比错误数据与正确数据。主要是看错误数据与正确数据相比是否有规律
- 根据现象定位链路环节的错误。目前出现的问题是数据打乱，内容非随机值，该问题可能是多个原因共同导致。一来Curl本身是多线程工作，下载和存盘的线程是否做好同步关系；二来对于存盘是以512 Bytes为单位进行操作的，如果不足最小单位，则将会有Merge的工作，而这个工作是glibc还是文件系统来做需要确认，是否地址对齐需要确认等等。
- 解决问题。数据下载下来之后在内存中做对齐，这个地址再往下传输，就是用的对齐后的地址，提高传输速度和正确性
分段播放PWM音频的时候出现咔哒咔哒的断音？

PWM音频没有时钟进行同步，如果整个数据严格的同步传输将发生，如果由于系统调度或者其它原因数据没有及时准备数据将发生underrun，听感上存在断音。

使用DMA Descriptor Loop的方式，整体的音频数据的播放不依赖软件，Buffer靠DMA硬件自动轮转。同时多个Desc保证了有缓存数据，不会发生underrun，应用层只需要按照正常流程向buffer里填充数据即可。生产者和消费者的配合则需要PWM驱动靠信号量等进行同步。
产品板小批量试产，系统进入未知状态且指示灯亮弱蓝光，长按电源键不能关机（该功能RTC提供）？
- 软件方面
  - 检查RTC驱动。确认硬件电路与驱动功能是否匹配，RTC对于系统的保护机制是否正常配置。
  - 保护机制是否存在漏洞。软件需要使用硬件提供的机制尽可能的保护整个系统的生命周期。当前存在的问题是：BootRom开启开门狗，SPL结束阶段关闭看门狗，SPL引导起RTOS系统并在某个阶段开启RTC。第一阶段系统可靠性要看门狗保护，第三阶段系统可靠性要RTC保护，但是RTOS系统启动直到开启RTC的阶段是没有保护的。因此解决方案就是把关闭RTC的动作延迟到RTC开启之后
- 硬件方面
  - 晶振的谐振电容的容值。电容值的大小影响谐振频率（也就是会发生频偏）主要影响负载谐振频率和等效负载谐振电阻，与晶体一起决定振荡器电路的工作频率，通过调整负载电容，就可以将振荡器的工作频率微调到标称值（最佳值可以找到厂商测试）
  - 充电IC与电池的匹配。对于某一款电池它存在一个最大充电电流，而对于充电IC，充电电流可通过一个电阻器进行外部设置，结合两个可以找到最合适的阻值进行匹配
PWM音频结尾有POP音？
- 确认POP音的来源。对于结尾处的处理进行调试，通过控制部分函数的调用确认是否还存在
- 确认音频源质量。如果音频结尾处是高的波形，则在关闭设备的时候一定出现pop音
- 处理。可以对音源结尾处进行平滑（淡出）处理来削弱POP
TF卡多block读写错误？

具体细节参考 SD调试笔记文章
- 优先检查驱动层的协议是否正确。针对CMD12、CMD23、CMD25这三个命令的协议支持是否正确，这三个CMD都是针对多BLK写进行支持的命令
- 其次对整个数据通路的流转进行检查，地址是都有对齐。如果驱动中是4字节访问，但是文件系统或者其它层没有做地址对齐同样产生错误。
使用MPlayer播放406*720分辨率的视频，出现毛刺的现象？
- 调试过程
  
  整个播放过程涉及解码、旋转、合成、显示等步骤。通过在旋转后、framebuffer前将数据的每一帧进行存储，并通过软件查看视频格式是否正确确认数据在此阶段是否正常，经验证数据在写入framebuffer之后出现问题；进一步对驱动层进行调试，使用IMPP框架将一个RGB图片一个NV12图片合成做composer，并通过rdma将数据回读验证数据是否是在这一层出现的问题，经验证图片显示错误，也就是可以确认数据在做叠加的时候DPU模块出错。进一步通过阅读PM手册定位问题
- 问题点
  
  x1600 DPU控制器中LayerBufferAddr这个参数与NV12/NV21格式的视频需要8Byte对齐，但是406非对齐导致错误。可能出现的问题就是第一行地址访问没有问题，但是在第二行或者到nv数据的时候出现问题。
- 解决方案
  
  在MPlayer数据解码、旋转完成送入Framebuffer之前，将数据进行拷贝，填充（align_size - width）*height这些数据，保证数据对齐，送入FrameBuffer即可