前言
3 L7 ~3 U. Z/ f" c' T7 OSTM32H7 以太网的 MMC（MAC management counter）中断是个有点特别的中断。特殊之处在于它是默认使能。如果我们在代码里不针对 MMC 进行相关处理，就会造成一些异常现象。我们先来看一个真实的客户案例。

. r4 {" M) Z' u$ w/ N  W
. b: x1 V1 R) N5 h: ^, h客户案例
客户使用 STM32H750 作为主控，与其他设备之间进行以太网通讯。客户在压力测试中发现：
! N9 E4 Y7 k+ M• 设备从第一次通讯开始，累计 7 到 8 天，就会发现 STM32H750 不再响应用户的请求。
1 i) }; r9 ], U: g• 客户通过使用 IDE 和添加辅助代码可以发现，STM32H750 会不停地进入以太网中断，导致所使用的操作系统无法进行有效的系统调度。
- ]/ C. f: l! y  k• 问题发生后，客户无论拔下网线或者再次连上网线，STM32H750 依然会不停的进入以太网中断。
6 x4 P  C( W/ c$ f! ?• 客户尝试使用 IDE 查看所有以太网寄存器，会发现有时侯能够让系统恢复正常。
. P: u. {" @- k0 V

4 a7 x% E' ^0 ~# l5 g) R6 i$ b分析
系统不停的进入以太网中断，说明某个中断在被某种条件下被不停的触发，或者中断触发后没有被处理。进一步，当系统出现异常状况后，拔掉网线，中断依然不断的进入，说明该异常并不需要外界不停的输入，也就说明可能是中断没有被处理所导致。所以，客户首先想到的是补全所有使能的以太网中断的清除代码。然而，客户再次测试，却发现累计 7 到 8 天，问题再次发生。
! q  b) `3 G: r, g$ a7 \0 a在这种情况下，为了深刻了解该状况的原因，我们建议客户，抓取异常时的寄存器现场，然后和正常状态时的寄存器进行对比。我们在设备未发生异常前，抓取了以太网的三组寄存器 DMA、MTL 和 MAC。同时，我们在发生异常后，在同一设备再次进行这三组寄存器的抓取。然后，我们使用文本比较工具，对两次的寄存器进行比较。我们很快就可以发现，MAC 寄存器存在值得关注的差异。MAC 寄存器对比如下：


( B4 K7 X  v6 Y4 h) R
) V# \* E1 M( I4 C  j* ^! Q我们可以看到在系统异常情况下下，MMCRXIS 和 MMCIS 被置位了。
( Y2 ~: Q" p" u; I( K我们从参考手册 RM0433 (STM32H742, STM32H743/753 and STM32H750 Value line
/ z" N7 D: [: m5 I- Nadvanced Arm®-based 32-bit MCUs)（直接搜索关键子 MMCRXIS）中可以看到 MMCRXIS 和
* K/ Z' A9 G9 o% _( GMMCIS 表示系统收到了 MMC 接收中断。






在两次三组寄存器的比较中，我们看到系统生成了 MMC 接收中断（MMC_RX_INTERRUPT 中RXUCGPIS）。这个符合前文的 MMCRXIS 和 MMCIS 的状态。

' y, j5 f' t4 {# @. `, j0 e完整版请查看：附件

# R. b3 e# t0 @) m0 |! \
5 w, U! M/ }1 v' v1 Q7 Q, }( j$ w+ q
7 B: X' k. Z$ g$ W  c
7 A! C( v2 L8 ~, x* s8 p* V