项目场景:
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操作。把问题集中到这个点上进一步分析:
==》</

文章讲述了在项目中遇到的USBAudio芯片问题,涉及代码执行时的参数保存、FPGA验证中的干扰,以及与DCO频率、中断、内存访问等相关的卡死现象。通过深入分析和硬件软件配合,最终定位到qspiflash的suspend/resume操作时机问题,软件层面通过关闭中断和优化配置解决了大部分问题。

1700

被折叠的 条评论
为什么被折叠?



