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

项目场景：

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