【经验分享】STM32H7 以太网的 MMC 中断

STMCU-管管 · 2021-12-15T02:26:39+00:00

前言& a' y/ V R* K, S STM32H7 以太网的 MMC（MAC management counter）中断是个有点特别的中断。特殊之处在于它是默认使能。如果我们在代码里不针对 MMC 进行相关处理，就会造成一些异常现象。我们先来看一个真实的客户案例。 3 @0 A3 P% }+ {! U t5 n 5 y$ g. _1 ^1 n客户案例" f% x6 @/ C1 e 客户使用 STM32H750 作为主控，与其他设备之间进行以太网通讯。客户在压力测试中发现：& Q6 u) n7 J" C : Z! I: d% S& y·设备从第一次通讯开始，累计 7 到 8 天，就会发现 STM32H750 不再响应用户的请求。 1 E. y( a; O" f4 @$ h" M·客户通过使用 IDE 和添加辅助代码可以发现，STM32H750 会不停地进入以太网中断，导致所使用的操作系统无法进行有效的系统调度。 # S- ]$ g% j5 Q9 ?) O·问题发生后，客户无论拔下网线或者再次连上网线，STM32H750 依然会不停的进入以太网中断。 7 _4 q! I% y- B8 e4 f·客户尝试使用 IDE 查看所有以太网寄存器，会发现有时侯能够让系统恢复正常。 / g4 T, m+ g% U, H4 z8 [- c" T9 n$ \6 X* Q' x/ Y4 Q# d8 _# h 分析; h; g% \5 Y2 Q- O! e, c7 l9 N 系统不停的进入以太网中断，说明某个中断在被某种条件下被不停的触发，或者中断触发后没有被处理。进一步，当系统出现异常状况后，拔掉网线，中断依然不断的进入，说明该异常并不需要外界不停的输入，也就说明可能是中断没有被处理所导致。所以，客户首先想到的是补全所有使能的以太网中断的清除代码。然而，客户再次测试，却发现累计 7 到 8 天，问题再次发生。在这种情况下，为了深刻了解该状况的原因，我们建议客户，抓取异常时的寄存器现场，然后和正常状态时的寄存器进行对比。我们在设备未发生异常前，抓取了以太网的三组寄存器 DMA、MTL 和 MAC。同时，我们在发生异常后，在同一设备再次进行这三组寄存器的抓取。然后，我们使用文本比较工具，对两次的寄存器进行比较。我们很快就可以发现，MAC 寄存器存在值得关注的差异。MAC 寄存器对比如下：: g M1 M* ]' F F # J0 s3 Z; b$ q ▲图 1 MAC 寄存器对比我们可以看到在系统异常情况下下，MMCRXIS 和 MMCIS 被置位了。( O+ Q4 t2 A, _% p 3 E; p5 N# E5 H3 Y: k0 x 我们从参考手册 RM0433 (STM32H742, STM32H743/753 and STM32H750 Value line advanced Arm®-based 32-bit MCUs)（直接搜索关键子 MMCRXIS）中可以看到MMCRXIS 和MMCIS 表示系统收到了MMC 接收中断。( m( b7 q7 v, | ( _, S. h7 S- d0 b: J ▲图 2 MMCRXIS 与 MMCIS 置位的含义. F" V ^, Y0 ^! ?1 m 在两次三组寄存器的比较中，我们看到系统生成了 MMC 接收中断（MMC_RX_INTERRUPT 中RXUCGPIS）。这个符合前文的MMCRXIS 和MMCIS 的状态。 6 ~2 f2 n7 L+ _( J9 G" Q# H L ▲图 3 MMC_RX_INTERRUPT 的比较从参考手册 RM0433 中我们可以看到，只要MMC 选项使能，该中断标志就为有效。但是我们并没有使能MMC 选项，甚至我们都没有使能 MMC 中断，为什么还是有中断产生呢？! W0 ] l" D1 f8 Z& e/ n, l # c `3 @0 d* ]) a " i2 N5 C( }; X" `2 \ FMMC 中断的特点 5 o7 ?7 j }( t) i+ f) V, _) F# l7 ], p v# x! Q# A9 N% o 6 p# b8 K W9 C3 w# P MMC 选项其实是默认使能。我们可以从参考手册 RM0433 中看到这一点。; L( N+ C0 B+ @, ~. g( t 2 _4 E5 o% I) _ ▲图 4 MAC management counters 9 y$ J: \, p5 p* O' T% S/ i; U7 D; M1 |, _ / ?$ U3 S( H3 |( f0 _# t 在 MMC 默认使能的情况下，什么情况下会产生中断呢？ 6 l8 q6 R/ q5 i/ C5 Q3 j) J6 [: R ; v2 Z, _2 i- A+ Q- ]5 ~( r+ a( D) i, ~1 d' Q+ c' { 让我们在 RM0433 里搜索下两次寄存器比较发现的 RXUCGPIS 寄存器:: a& G6 l& _6 M / i; c7 V* c& l2 V8 c$ e ▲图 5 RXUCGPIS . u1 a4 m# a2 p5 P: |; q) }! i! `! l9 s + {, Q l! k6 S2 }0 x3 [, t" e- I 我们可以看到MMC 接收中断会在统计值最大的一半或者最大值时会产生。这也和MMC RX interrupt register 开始的说明描述一致。, \! J( O/ f4 ~4 R ; \( s% j4 }+ H▲图 6 MMC Receive Interrupt 的条件. `0 M2 `) g6 a3 t5 o9 Q n7 g1 Q* ^ - B) j3 ~8 b+ T9 s, C' ^$ [/ D 综合这两点，我们可以认为，在长时间以太网收发包之后，MMC 中断几乎一定会发生。这符合客户案例的场景，例如，重现这个问题需要 7 到 8 天。当然从这里我们也可以推断出，我们如果加快测试数据包收发的发送，MMC 中断会发生更早。那么，如何避免在产品应用中这种问题发生呢?, M9 U4 D2 y l7 K 解决方案 8 J* Y6 L- G' }& p- o) v1.1.使用MMC 中断 1 Z* e0 R- a% r/ a- y/ \5 _) @MMC 中断是个有用的功能。如果我们要使用的话，可以参考 MMC Rx interrupt register(ETH_MMC_RX_INTERRUPT)和 MMC Tx interrupt register (ETH_MMC_TX_INTERRUPT)的描述。我们需要对MMC 进行一个读的操作。5 v% l5 `; ?3 c5 Q, P1 B' \, U 5 v- S8 j) ~% u( { o* G: l" ` ▲图 7 MMC Receive Interrupt 清除的方法 ! l! X1 l, d" s2 D) ~ ) l: G9 Q7 q1 i, ~! P3 ?7 P) b: X7 J" G1 P2 r. Q( ?: I 以及6 c1 h( D3 v1 C3 h * s# J# d: G B/ @1 O, N |▲图 8 MMC Transmit Interrupt register 清除的方法 + E6 n& G4 I$ W7 H4 d& o5 |2 {5 q( b4 C6 f9 P ( f- `$ t9 k- z$ k8 C 这也解释了，客户为什么发现，通过调试器一个一个去读取以太网寄存器，会在某个操作时让异常状态恢复到正常。 5 T6 P2 _% r3 ?. A2 J/ ~9 S6 s5 b! j+ l! |5 W, n, r # x* P' Z3 o! P/ ]" Q 1.2. 关闭 MMC 中断 ( ] X! C- o2 I6 v9 I% V在很多情况下，MMC 中断对实际产品没有意义。例如，在这个案例中，我们可以选择关闭 MMC中断。这就需要用到 MMC 中断的 mask 寄存器： 7 V1 B" A9 W9 r# _0 U6 @. ]% P8 |5 K" _, }+ T: T5 W# W 6 p8 @/ j0 K( [) FMMC Rx interrupt mask register (ETH_MMC_RX_INTERRUPT_MASK) 5 E% J' O4 J# {: n+ o$ OMMC Tx interrupt mask register (ETH_MMC_TX_INTERRUPT_MASK) 8 u. B' X) o0 e v; h" k7 G8 ^+ `# c1 s8 L$ ^8 s) O( X ' b, C9 \5 Y0 \/ z 我们可以添加以下代码到我们的应用代码里 ( h. O7 v' G7 t" `7 f5 B+ X J3 h$ z0 V! Q * F5 y1 b' w2 A% L8 e ETH->MMCRIMR = ETH_MMCRIMR_RXLPITRCIM | ETH_MMCRIMR_RXLPIUSCIM | ( K- o* M) v4 k+ c7 ]/ ~0 ~ ETH_MMCRIMR_RXUCGPIM | ETH_MMCRIMR_RXALGNERPIM | ETH_MMCRIMR_RXCRCERPIM; ; o9 R0 ^1 ^7 YETH->MMCTIMR = ETH_MMCTIMR_TXLPITRCIM | ETH_MMCTIMR_TXLPIUSCIM | + v) ^; G& i8 H0 G- HETH_MMCTIMR_TXGPKTIM | ETH_MMCTIMR_TXMCOLGPIM | ETH_MMCTIMR_TXSCOLGPIM;9 H6 q8 N- h8 w+ G ) b% m; T N, W) S% b7 e7 b客户反馈找不到 ETH 的定义。其实在 STM32H7 的例程里，我们可以很容易发现 ETH 定义在STM32Cube\Repository\STM32Cube_FW_H7_V1.8.0\Drivers\CMSIS\Device\ST\STM32H7xx\Include\stm32h750xx.h：4 H0 S, n5 I/ k$ h' P3 N" y6 J " o3 X0 F% u# ^2 F/ b0 B% u( U8 U% Z- R) f& U5 \; u4 l #define ETH ((ETH_TypeDef *)ETH_BASE) 2 m9 L2 l) n% v- f 6 n% w6 A. e4 N5 H: _! J# L, y也就是说，如果你的工程时源自 STM32Cube 例程，你应该能够加入以上代码并且能够成功运行。 + ?7 {) V% a; p7 {" | $ _* g# v/ u8 Y- a h# l在加入上述代码或者类似操作后，客户反馈，再次进行超过 7 天以上的压力测试，系统运行正常。 * `7 i" [$ y8 b. c+ I/ c, O . X0 J }1 ]. }9 T6 s总结 7 J- Y" N$ ^$ R& P& Z4 \1 Z6 m# R! T7 a& ^ STM32H7 的 MMC 中断需要加以注意，如果不使用 MMC，需要确保它已经关闭；否则在经过长时间网络收发后，系统会产生并不是用户期望的中断，导致系统假死。另外，我们也看到了调试STM32 以太网的常规方式，也就是借助工具而不需要写代码就可以进行寄存器的比较。这种方法值得使用 STM32 以太网的用户进行调试时参考。 6 C; d7 \! v. h" c+ C s

[复制链接]

STMCU-管管发布时间：2021-12-15 10:26

技术帖
文章封面:
文章简介:	STM32H7 以太网的 MMC（MAC management counter）中断是个有点特别的中断。特殊之处在于它是默认使能。如果我们在代码里不针对 MMC 进行相关处理，就会造成一些异常现象。我们先来看一个真实的客户案例。

前言

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

客户案例

客户使用 STM32H750 作为主控，与其他设备之间进行以太网通讯。客户在压力测试中发现：

·设备从第一次通讯开始，累计 7 到 8 天，就会发现 STM32H750 不再响应用户的请求。
·客户通过使用 IDE 和添加辅助代码可以发现，STM32H750 会不停地进入以太网中断，导致所使用的操作系统无法进行有效的系统调度。
·问题发生后，客户无论拔下网线或者再次连上网线，STM32H750 依然会不停的进入以太网中断。
·客户尝试使用 IDE 查看所有以太网寄存器，会发现有时侯能够让系统恢复正常。

分析

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

▲图 1 MAC 寄存器对比

我们可以看到在系统异常情况下下，MMCRXIS 和 MMCIS 被置位了。

我们从参考手册 RM0433 (STM32H742, STM32H743/753 and STM32H750 Value line advanced Arm®-based 32-bit MCUs)（直接搜索关键子 MMCRXIS）中可以看到MMCRXIS 和MMCIS 表示系统收到了MMC 接收中断。

▲图 2 MMCRXIS 与 MMCIS 置位的含义

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

▲图 3 MMC_RX_INTERRUPT 的比较

从参考手册 RM0433 中我们可以看到，只要MMC 选项使能，该中断标志就为有效。但是我们并没有使能MMC 选项，甚至我们都没有使能 MMC 中断，为什么还是有中断产生呢？

MMC 中断的特点

MMC 选项其实是默认使能。我们可以从参考手册 RM0433 中看到这一点。

▲图 4 MAC management counters

在 MMC 默认使能的情况下，什么情况下会产生中断呢？

让我们在 RM0433 里搜索下两次寄存器比较发现的 RXUCGPIS 寄存器:

▲图 5 RXUCGPIS

我们可以看到MMC 接收中断会在统计值最大的一半或者最大值时会产生。这也和MMC RX interrupt register 开始的说明描述一致。

▲图 6 MMC Receive Interrupt 的条件

综合这两点，我们可以认为，在长时间以太网收发包之后，MMC 中断几乎一定会发生。这符合客户案例的场景，例如，重现这个问题需要 7 到 8 天。当然从这里我们也可以推断出，我们如果加快测试数据包收发的发送，MMC 中断会发生更早。那么，如何避免在产品应用中这种问题发生呢?

解决方案

1.1.使用MMC 中断
MMC 中断是个有用的功能。如果我们要使用的话，可以参考 MMC Rx interrupt register(ETH_MMC_RX_INTERRUPT)和 MMC Tx interrupt register (ETH_MMC_TX_INTERRUPT)的描述。我们需要对MMC 进行一个读的操作。

▲图 7 MMC Receive Interrupt 清除的方法

以及

▲图 8 MMC Transmit Interrupt register 清除的方法

这也解释了，客户为什么发现，通过调试器一个一个去读取以太网寄存器，会在某个操作时让异常状态恢复到正常。

1.2. 关闭 MMC 中断
在很多情况下，MMC 中断对实际产品没有意义。例如，在这个案例中，我们可以选择关闭 MMC中断。这就需要用到 MMC 中断的 mask 寄存器：

MMC Rx interrupt mask register (ETH_MMC_RX_INTERRUPT_MASK)
MMC Tx interrupt mask register (ETH_MMC_TX_INTERRUPT_MASK)

我们可以添加以下代码到我们的应用代码里

ETH->MMCRIMR = ETH_MMCRIMR_RXLPITRCIM | ETH_MMCRIMR_RXLPIUSCIM |
ETH_MMCRIMR_RXUCGPIM | ETH_MMCRIMR_RXALGNERPIM | ETH_MMCRIMR_RXCRCERPIM;
ETH->MMCTIMR = ETH_MMCTIMR_TXLPITRCIM | ETH_MMCTIMR_TXLPIUSCIM |
ETH_MMCTIMR_TXGPKTIM | ETH_MMCTIMR_TXMCOLGPIM | ETH_MMCTIMR_TXSCOLGPIM;

客户反馈找不到 ETH 的定义。其实在 STM32H7 的例程里，我们可以很容易发现 ETH 定义在STM32Cube\Repository\STM32Cube_FW_H7_V1.8.0\Drivers\CMSIS\Device\ST\STM32H7xx\Include\stm32h750xx.h：

#define ETH ((ETH_TypeDef *)ETH_BASE)

也就是说，如果你的工程时源自 STM32Cube 例程，你应该能够加入以上代码并且能够成功运行。

在加入上述代码或者类似操作后，客户反馈，再次进行超过 7 天以上的压力测试，系统运行正常。

总结

STM32H7 的 MMC 中断需要加以注意，如果不使用 MMC，需要确保它已经关闭；否则在经过长时间网络收发后，系统会产生并不是用户期望的中断，导致系统假死。另外，我们也看到了调试STM32 以太网的常规方式，也就是借助工具而不需要写代码就可以进行寄存器的比较。这种方法值得使用 STM32 以太网的用户进行调试时参考。