服装商城的网站建设,网站如何批量上传产品,怎样用代码做网站,怎样做相亲网站项目场景#xff1a;
USB Audio芯片#xff0c;代码放到qspi flash中#xff0c;执行代码时#xff0c;客户会偶尔保存一些参数#xff0c;即FPGA验证过程中#xff0c;每隔10ms向flash info区烧写4个byte#xff08;取指过程一直存在#xff0c;且时隙软件不可控
USB Audio芯片代码放到qspi flash中执行代码时客户会偶尔保存一些参数即FPGA验证过程中每隔10ms向flash info区烧写4个byte取指过程一直存在且时隙软件不可控同时芯片同时打开录音功能以及DAC播放功能、以及打开系统中其他中断模块程序会被频繁打断。 问题描述 首次问题为通过电脑端点击录音和播放切换按钮发现偶尔会卡死概率性的问题运气好几十次会复现运气不好几百次才卡死。 原因分析
》
首先软件根据卡死时的pc dump出来所有通用寄存器分析出来卡死的具体位置并将现场打印出来通过对比现场与dump的指令发现卡死时从flash取到的几个指令错误导致CPU跑飞了。
》
根据此现象做进一步分析通过示波器测量了DCO的频率发现调节DCO频率时导致FPGA主频超频这种情况下我们基本上认为取指错误是超频导致的。后来也发现每次软件进入调节DCO函数时就会死掉那么基本上认为就是这个原因了。因此我们把调节DCO控制字关闭掉简化测试环境始终让DCO工作在一个稳定的时钟频率下再次进行压力测试。
》
进一步做压力测试发现还是偶尔会卡死只是概率更低了基本上都是几百次才死一次。同样根据现场与dump进行指令比对发现卡死的时候还是有取指错误。那么我们把cache关掉再次取flash发生错误的这个地址这次取的是正确的指令。这说明前面有一次取指错误被cache住了而且可以排除cache的问题因为单步调试再次取错误地址时指令是正确的。
》
进一步分析现在基本上确定是flash这边的问题那么根据case我们发现这个时候对应着xip读flash且同时进行program操作即对于flash来说会有suspend和resume操作。把问题集中到这个点上进一步分析
》
从多次复现的现象上看基本上死的时刻都发生在开始program时刻即cs_n拉高然后大概50us的时候CPU来了xip 读操作。然后我们结合datasheet给的suspend时间以及软件单测program 4个byte的时候进行分析发现可能是因为flash内部还没有真正接收suspend挂起命令就来了xip 读操作了导致的。
》
因此我们查看datasheet发现里面有要求再发起suspend命令前一定要轮询flash的状态寄存器busy以及suspend bit然后满足特定条件时才能发起suspend命令0x75而我们的硬件qspi controller设计并没有完全按照这个要求来而是选择了一个等待时间的方式认为cs_n拉高后满足datasheet给的时间后一定会出现busy/suspend满足要求但是实际芯片测试不一定是这样的按照IP vendor给的建议最后是直接轮询内部的状态寄存器。
》
考虑到目前我们的芯片已经tap out硬件暂时没有改的机会目前通过软件来绕
软件在发起program后关闭中断70us这个关中断时间保证了此期间没有xip 读操作即这个时间差不多program也完成了4个byte的烧写因此就不会真正出现suspend的操作了。后来我们用这种方式继续进行压力测试发现了跑着跑着usb的in包数据突然没有了初步怀疑是关这70us的中断导致CPU丢了usb的中断导致软件没有及时填tx fifo导致断音。因此我们把场景降到FS模式这样1ms处理一次usb 中断理论上来说发生断音的概率几乎没有但是事实上还是有因此我们分析可能并不是关中断导致的断音。
》
进一步分析
因为之前开的usb FIFO为双buffer乒乓填数据现在为了简化case改成单buffer结构这样故障概率会加大另外软件把ahb的频率降低排除timing问题。根据此配置继续debug发现仍然有问题。
》
进一步分析通过FPGA抓取一些内部信号分析考虑到FPGA资源有限关键点需要找到适合的trigger我们先将问题定位到中断上因此先抓一下原始中断、CPU中断口中断使能分析一下。这个时候我们发现确实原始中断没有起来因此我们怀疑可能是host端没有发送数据请求因此我们更进一步简化验证平台的环境想到了目前芯片接到hub由hub接到CPU的USB口因此我们把hub拿掉直接将芯片接到电脑的USB口再去试试。
这样我们压力测试了一天一夜没有发现问题说明之前导致的问题就是因为hub上可能接的东西太多了导致传输不稳定导致的。
》
为了double check我们在RTL级别修改了一些qspi控制器完全完整datasheet要求在发suspend及resume之前先去读busy和suspend状态寄存器。再次进行压力测试没有发现问题。
说明以上问题就是因为设计不鲁棒导致的。 解决方案
1. 目前针对已经tap out的芯片我们利用软件绕的方式来规避这个问题。
2. 针对后续项目将采样fix bug后的controller设计
