QSPI Flash xip取指同时program过程中概率性出现usb播歌时断音

2023-12-29 09:29:09

项目场景:

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设计

文章来源:https://blog.csdn.net/luyil/article/details/135282191
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。