你的浏览器版本过低,可能导致网站不能正常访问!
为了你能正常使用网站功能,请使用这些浏览器。

STM32H7 以太网的 MMC 中断

[复制链接]
STMCU小助手 发布时间:2022-9-10 18:32
1、前言
STM32H7 以太网的 MMC(MAC management counter)中断是个有点特别的中断。特殊之处在于它是默认使能。如果我们在代码里不针对 MMC 进行相关处理,就会造成一些异常现象。我们先来看一个真实的客户案例。
; g( }  \- ]$ K; C5 W' q" j

" t& b. j, ~' s  |/ }% D( {, L* I
2、客户案例
客户使用 STM32H750 作为主控,与其他设备之间进行以太网通讯。
! Y, J. @- B% M$ E
客户在压力测试中发现:

' K9 O4 ^, K7 ?9 S7 j  \- r, o
• 设备从第一次通讯开始,累计 7 到 8 天,就会发现 STM32H750 不再响应用户的请求。
• 客户通过使用 IDE 和添加辅助代码可以发现,STM32H750 会不停地进入以太网中断,导致所使用的操作系统无法进行有效的系统调度。
• 问题发生后,客户无论拔下网线或者再次连上网线,STM32H750 依然会不停的进入以太网中断。
• 客户尝试使用 IDE 查看所有以太网寄存器,会发现有时侯能够让系统恢复正常。
3 U' z! |, A3 H2 M9 e( r# [
3 G/ Q7 T( H- {* o4 H
3、分析
系统不停的进入以太网中断,说明某个中断在被某种条件下被不停的触发,或者中断触发后没有被处理。进一步,当系统出现异常状况后,拔掉网线,中断依然不断的进入,说明该异常并不需要外界不停的输入,也就说明可能是中断没有被处理所导致。所以,客户首先想到的是补全所有使能的以太网中断的清除代码。然而,客户再次测试,却发现累计 7 到 8 天,问题再次发生。
' g# ]7 X' X' d+ ?) ^; v
在这种情况下,为了深刻了解该状况的原因,我们建议客户,抓取异常时的寄存器现场,然后和正常状态时的寄存器进行对比。我们在设备未发生异常前,抓取了以太网的三组寄存器 DMA、 MTL 和 MAC。同时,我们在发生异常后,在同一设备再次进行这三组寄存器的抓取。然后,我们使用文本比较工具,对两次的寄存器进行比较。我们很快就可以发现,MAC 寄存器存在值得关注的差异。MAC 寄存器对比如下:

3 O6 z) m" r; `4 J/ u
微信图片_20220910183203.png

4 e+ W) t6 \5 g+ i! u( P
我们可以看到在系统异常情况下下,MMCRXIS 和 MMCIS 被置位了。
我们从参考手册 RM0433 (STM32H742, STM32H743/753 and STM32H750 Value line advanced Arm®-based 32-bit MCUs)(直接搜索关键子 MMCRXIS)中可以看到 MMCRXIS 和 MMCIS 表示系统收到了 MMC 接收中断。
# O: a3 W1 ]" i7 @, W$ O/ {
微信图片_20220910183200.png
3 r, J* E  G$ Q/ H, _
在两次三组寄存器的比较中,我们看到系统生成了 MMC 接收中断(MMC_RX_INTERRUPT 中 RXUCGPIS)。这个符合前文的 MMCRXIS 和 MMCIS 的状态。

* {$ A+ v5 F% P
4 i& u0 v7 e5 ^5 t% Z
微信图片_20220910183156.png

, I7 Z3 t7 U1 q, z2 L: e9 u
从参考手册 RM0433 中我们可以看到,只要 MMC 选项使能,该中断标志就为有效。但是我们并没有使能 MMC 选项,甚至我们都没有使能 MMC 中断,为什么还是有中断产生呢?
* J+ C9 a% W7 g* p7 m7 o5 s7 ~
4 @  V8 k: s+ w  h$ A# ?/ b

# P: _$ A3 I$ e; z3 w2 T
4、MMC 中断的特点
MMC 选项其实是默认使能。我们可以从参考手册 RM0433 中看到这一点。
) X2 p1 u' H) E  k; c
微信图片_20220910183153.png

) c. b2 ~* c! \8 H, A8 j
( y# t0 o/ a; Q, R2 }( l
在 MMC 默认使能的情况下,什么情况下会产生中断呢?
让我们在 RM0433 里搜索下两次寄存器比较发现的 RXUCGPIS 寄存器:
9 C6 G5 k! d( ^- b* q5 d
微信图片_20220910183150.png
7 r: ^+ G! O8 R& s0 l: ?7 G6 U
综合这两点,我们可以认为,在长时间以太网收发包之后,MMC 中断几乎一定会发生。这符合客户案例的场景,例如,重现这个问题需要 7 到 8 天。当然从这里我们也可以推断出,我们如果加快测试数据包收发的发送,MMC 中断会发生更早。那么,如何避免在产品应用中这种问题发生呢?
$ I; b, X! a) A/ k3 o/ ^
0 Y( {+ G0 ?' n/ e+ L  u6 x" Z% d

, E( k' @  c! M5 a) n- W  ?
5、解决方案
1.1. 使用 MMC 中断
MMC 中断是个有用的功能。如果我们要使用的话,可以参考 MMC Rx interrupt register  (ETH_MMC_RX_INTERRUPT)和 MMC Tx interrupt register (ETH_MMC_TX_INTERRUPT)的描述。我们需要对 MMC 进行一个读的操作。
2 h! r! @0 h2 @  R
微信图片_20220910183142.png
微信图片_20220910183139.png

+ H% x; f4 u& u& ^1 `2 i6 w
这也解释了,客户为什么发现,通过调试器一个一个去读取以太网寄存器,会在某个操作时让异常状态恢复到正常。
  x1 r# p# e- Y2 M! E: c5 r/ y& U
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)
我们可以添加以下代码到我们的应用代码里

, Y; c3 o: ~5 x$ B1 v: N( W+ X
微信图片_20220910182748.png
- o- Q: x" J; V7 g% Y8 P3 X' R
客户反馈找不到 ETH 的定义。其实在 STM32H7 的例程里,我们可以很容易发现 ETH 定义在
STM32Cube\Repository\STM32Cube_FW_H7_V1.8.0\Drivers\CMSIS\Device\ST\STM32H7xx\Include\stm32h750xx.h:
+ H! f6 `  Z7 ^+ N8 i
微信图片_20220910182734.png

$ b; O* p( z- L4 |9 [% A9 a
也就是说,如果你的工程代码源自 STM32Cube 例程,你应该能够加入以上代码并且能够成功运行。
在加入上述代码或者类似操作后,客户反馈,再次进行超过 7 天以上的压力测试,系统运行正常。
+ u- ?  ]6 R9 y* d1 `
' t! o  t# G& e, @/ c0 }$ K
6、总结
STM32H7 的 MMC 中断需要加以注意,如果不使用 MMC,需要确保它已经关闭;否则在经过长时间网络收发后,系统会产生并非用户所期望的中断,导致系统假死。另外,我们也看到了调试STM32 以太网的常规方式,也就是借助工具而不需要写代码就可以进行寄存器的比较。这种方法值得使用 STM32 以太网的用户进行调试时参考。
$ ?9 C1 a. z! m+ Z! G0 m- w
赞 收藏 评论0 发布时间:2022-9-10 18:32

举报

0个回答

所属标签

相似技术帖

官网相关资源

关于
我们是谁
投资者关系
意法半导体可持续发展举措
创新与技术
意法半导体官网
联系我们
联系ST分支机构
寻找销售人员和分销渠道
社区
媒体中心
活动与培训
隐私策略
隐私策略
Cookies管理
行使您的权利
官方最新发布
人形机器人运动控制、感知与智能配电
半导体创新技术与应用方向
EE架构与软件定义汽车
12V/48V 汽车智能配电(SPD)
区域控制单元(ZCU)与分区架构
关注我们
st-img 微信公众号
st-img 手机版