系統壓力測試發現的問題通常都比較復雜，作者最近解決了一個有意思的系統穩定性問題，也想請各位讀者一起思考下，想想問題的原因是什么。

i.MXRT600/i.MXRT500/i.MXRT700 廣泛用AI眼鏡的應用中. 其中i.MXRT600,因為其優秀的音頻處理能力，在系統中，通常作為音頻協處理器使用。

i.MXRT600微控制器包括兩個內核ARM Cortex M33 以及 Cadence Xtensa HiFi4 AudioDSP， 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溢出中斷，在I2S0FIFO溢出中斷中，復位I2S0來保證I2S0狀態恢復到正常的狀態。

作者做了以下的驗證，確保這個功能的有效性。使用GPIO中斷，在GPIO中斷中暫停DMA1搬移I2S0到SRAM0的通道。由于DMA1停止了，I2S0FIFO溢出進入中斷處理函數，復位I2S, 此時重啟DMA1通道，下行音頻恢復。

可惜的是，這種方法并不奏效，在接下來的壓力測試中，I2S0 FIFO狀態寄存器（FIFOSTAT）顯示接收FIFO溢出，I2S0中斷服務程序可以進入，并重啟I2S0，但很快，I2S0 FIFO又馬上進入了溢出的狀態，DMA1完成中斷還是不能夠正常觸發，DMA沒有完成描述字要求的傳輸任務。

到底是什么原因導致DMA1不能完成從FIFO搬移到SRAM的任務呢？歡迎評論區留言，答案見下期揭曉~