MCU系统压力测试出现问题，该怎么办？

痞子衡嵌入式

系统压力测试发现的问题通常都比较复杂，作者最近解决了一个有意思的系统稳定性问题，也想请各位读者一起思考下，想想问题的原因是什么。欢迎评论区留言讨论~
i.MXRT600/i.MXRT500/i.MXRT700 广泛用AI眼镜的应用中. 其中i.MXRT600,因为其优秀的音频处理能力，在系统中，通常作为音频协处理器使用。
i.MXRT600微控制器包括两个内核ARM Cortex M33 以及 Cadence Xtensa HiFi4 Audio DSP， 4.5MB 片上SRAM. 以及两个DMA 控制器及I2S/PDM 等音频接口。
该系统大致框图如下所示：

系统包括应用处理器, i.MXRT600, 音频CODEC，以及麦克风。应用处理器作为I2S 主机通过I2S输送下行音频到RT600，DMA1用于搬移音频数据，HiFi4 DSP运行降噪，去回声等算法处理上下行音频。音频Codec和扬声器用于音频下行数据的播放，麦克风用于音频上行数据的采集。CM33和DMA0处理非音频的应用，CM33和HIFI4使用中断和共享内存通信。
系统在压力测试时，数小时后会出现下行音频停止的情况。
下行音频的路径如下图所示，I2S外设0(I2S0)配置为I2S SLAVE接收, 下行数据会存储到I2S0的FIFO中。DMA1从FC0的FIFO 搬移音频到SRAM_0, HIFI4处理在SRAM_0的数据输入并将处理结果放在SRAM_1。最后，DMA1搬移SRAM_1中的数据到I2S外设1(I2S1) FIFO, I2S1被配置为I2S MASTER 发送模式。

通过在DMA中断回调函数中翻转IO调试显示，当下行音频停止的时候，DMA1搬运I2S0数据到SRAM_0的中断不能在进入了。这个问题的范围也就缩小到DMA1从I2S0的FIFO拷贝数据到SRAM_0的过程。
当问题出现时，停下HiFi4内核，使用调试器观察DMA1 和 I2S0的寄存器。DMA1控制器的DMA状态寄存器和DMA通道状态寄存器都是正确的。DMA1通道寄存器显示传输正在进行。而I2S1 状态寄存器显示了2个异常情况。1. I2S0 状态寄存器（STAT）显示SLVFRAMEERR, Slave Frame Error.2. I2S0 FIFO状态寄存器（FIFOSTAT）显示接收FIFO溢出，但当前FIFO中数据为空。异常情况1只发生在I2S做SLAVE从机时产生。错误的原因是I2S SCK信号和WS信号不匹配。I2S每个SCK时钟周期传输1个音频位，如果一个音频采样是16位，双声道传输的情况，那么在一个WS的低电平（高电平）脉冲应该对应16个SCK的时钟。当SCK和WS不匹配时，就会出现SLVFRAMEERR错误。

一个关于问题原因猜想是，FRAME ERROR导致I2S0不能再正常工作，从而DMA1无法从I2S0 FIFO中取到音频数据而导致下行音频链路终止。
为了证实这个猜想，作者做了如下实验, 分别短时间断开I2S0输入的WS信号和CLK信号，看DMA1是不是会因为WS或者CLK的停止而停止，随着WS/CLK的恢复而恢复。答案是肯定的，当I2S0的输入WS或者CLK信号断开时，DMA由于没有数据可搬运从而停止，当WS或CLK恢复时，I2S SLAVE会根据WS信号重新同步数据并接收数据到I2S FIFO，DMA也可以继续完成未完成的传输。而FRAME ERROR会置位，但这种WS/CLK丢失导致的FRAME ERROR不是关键的致命错误。同时，在这种情况下I2S FIFO寄存器也没有出现溢出的错误。

由于DMA1 控制器工作正常，在压力测试期间很难监控I2S信号来分析I2S FRAME ERROR 和FIFO溢出产生的原因，作者计划使用HiFi4通过处理I2S0的FIFO溢出中断，在I2S0 FIFO溢出中断中，复位I2S0来保证I2S0状态恢复到正常的状态。

作者做了以下的验证，确保这个功能的有效性。使用GPIO中断，在GPIO中断中暂停DMA1搬移I2S0到SRAM0的通道。由于DMA1停止了，I2S0 FIFO溢出进入中断处理函数，复位I2S, 此时重启DMA1通道，下行音频恢复。
可惜的是，这种方法并不奏效，在接下来的压力测试中，I2S0 FIFO状态寄存器（FIFOSTAT）显示接收FIFO溢出，I2S0中断服务程序可以进入，并重启I2S0，但很快，I2S0 FIFO又马上进入了溢出的状态，DMA1完成中断还是不能够正常触发，DMA没有完成描述字要求的传输任务。
到底是什么原因导致DMA1不能完成从FIFO搬移到SRAM的任务呢？欢迎评论区留言，答案见下期揭晓~