STM32H7 以太網(wǎng)的 MMC（MAC management counter）中斷是個有點特別的中斷。特殊之處在于它是默認使能。如果我們在代碼里不針對 MMC 進行相關(guān)處理，就會造成一些異?，F(xiàn)象。我們先來看一個真實的客戶案例。
客戶案例
客戶使用 STM32H750 作為主控，與其他設(shè)備之間進行以太網(wǎng)通訊?？蛻粼趬毫y試中發(fā)現(xiàn)：
? 設(shè)備從第一次通訊開始，累計 7 到 8 天，就會發(fā)現(xiàn) STM32H750 不再響應(yīng)用戶的請求。
? 客戶通過使用 IDE 和添加輔助代碼可以發(fā)現(xiàn)，STM32H750 會不停地進入以太網(wǎng)中斷，導(dǎo)致所使用的操作系統(tǒng)無法進行有效的系統(tǒng)調(diào)度。
? 問題發(fā)生后，客戶無論拔下網(wǎng)線或者再次連上網(wǎng)線，STM32H750 依然會不停的進入以太網(wǎng)中斷。
? 客戶嘗試使用 IDE 查看所有以太網(wǎng)寄存器，會發(fā)現(xiàn)有時侯能夠讓系統(tǒng)恢復(fù)正
常。
分析
系統(tǒng)不停的進入以太網(wǎng)中斷，說明某個中斷在被某種條件下被不停的觸發(fā)，或者中斷觸發(fā)后沒有被處理。進一步，當(dāng)系統(tǒng)出現(xiàn)異常狀況后，拔掉網(wǎng)線，中斷依然不斷的進入，說明該異常并不需要外界不停的輸入，也就說明可能是中斷沒有被處理所導(dǎo)致。所以，客戶首先想到的是補全所有使能的以太網(wǎng)中斷的清除代碼。然而，客戶再次測試，卻發(fā)現(xiàn)累計 7 到 8 天，問題再次發(fā)生。
在這種情況下，為了深刻了解該狀況的原因，我們建議客戶，抓取異常時的寄存器現(xiàn)場，然后和正常狀態(tài)時的寄存器進行對比。我們在設(shè)備未發(fā)生異常前，抓取了以太網(wǎng)的三組寄存器 DMA、MTL 和 MAC。同時，我們在發(fā)生異常后，在同一設(shè)備再次進行這三組寄存器的抓取。然后，我們使用文本比較工具，對兩次的寄存器進行比較。我們很快就可以發(fā)現(xiàn)，MAC 寄存器存在值得關(guān)注的差異。MAC 寄存器對比如下：

我們可以看到在系統(tǒng)異常情況下下，MMCRXIS 和 MMCIS 被置位了。我們從參考手冊 RM0433 (STM32H742, STM32H743/753 and STM32H750 Value lineadvanced Arm?-based 32-bit MCUs)（直接搜索關(guān)鍵子 MMCRXIS）中可以看到 MMCRXIS 和MMCIS 表示系統(tǒng)收到了 MMC 接收中斷.

在兩次三組寄存器的比較中，我們看到系統(tǒng)生成了 MMC 接收中斷（MMC_RX_INTERRUPT 中RXUCGPIS）。這個符合前文的 MMCRXIS 和 MMCIS 的狀態(tài)。

從參考手冊 RM0433 中我們可以看到，只要 MMC 選項使能，該中斷標(biāo)志就為有效。但是我們并沒有使能 MMC 選項，甚至我們都沒有使能 MMC 中斷，為什么還是有中斷產(chǎn)生呢？

后續(xù)更多內(nèi)容請您點擊下載全文