STMCU小助手
发布时间:2022-7-29 16:40
|
前言 STM32H7 以太网的 MMC(MAC management counter)中断是个有点特别的中断。特殊之处在于它是默认使能。如果我们在代码里不针对 MMC 进行相关处理,就会造成一些异常现象。我们先来看一个真实的客户案例。 客户案例 客户使用 STM32H750 作为主控,与其他设备之间进行以太网通讯。客户在压力测试中发现: • 设备从第一次通讯开始,累计 7 到 8 天,就会发现 STM32H750 不再响应用户的请求。 • 客户通过使用 IDE 和添加辅助代码可以发现,STM32H750 会不停地进入以太网中断,导致所使用的操作系统无法进行有效的系统调度。 • 问题发生后,客户无论拔下网线或者再次连上网线,STM32H750 依然会不停的进入以太网中断。 • 客户尝试使用 IDE 查看所有以太网寄存器,会发现有时侯能够让系统恢复正常。 分析 系统不停的进入以太网中断,说明某个中断在被某种条件下被不停的触发,或者中断触发后没有被处理。进一步,当系统出现异常状况后,拔掉网线,中断依然不断的进入,说明该异常并不需要外界不停的输入,也就说明可能是中断没有被处理所导致。所以,客户首先想到的是补全所有使能的以太网中断的清除代码。然而,客户再次测试,却发现累计 7 到 8 天,问题再次发生。 在这种情况下,为了深刻了解该状况的原因,我们建议客户,抓取异常时的寄存器现场,然后和正常状态时的寄存器进行对比。我们在设备未发生异常前,抓取了以太网的三组寄存器 DMA、MTL 和 MAC。同时,我们在发生异常后,在同一设备再次进行这三组寄存器的抓取。然后,我们使用文本比较工具,对两次的寄存器进行比较。我们很快就可以发现,MAC 寄存器存在值得关注的差异。MAC 寄存器对比如下:
我们可以看到在系统异常情况下下,MMCRXIS 和 MMCIS 被置位了。 我们从参考手册 RM0433 (STM32H742, STM32H743/753 and STM32H750 Value line advanced Arm®-based 32-bit MCUs)(直接搜索关键子 MMCRXIS)中可以看到 MMCRXIS 和 MMCIS 表示系统收到了 MMC 接收中断。
在两次三组寄存器的比较中,我们看到系统生成了 MMC 接收中断(MMC_RX_INTERRUPT 中RXUCGPIS)。这个符合前文的 MMCRXIS 和 MMCIS 的状态。 完整版请查看:附件 |
经验分享 | STM32H723 SPI 通讯异常排查:实时观察窗口的 “隐形干扰” 解决方案
经验分享 | STM32H7 SPI NSS 脉冲模式灵活应用:解决外置 ADC 通信干扰问题
经验分享 | STM32H7 双核调试配置:STM32CubeIDE 下 M7+M4 协同调试实操
经验分享 | STM32H7 TouchGFX 花屏速解:更换 HyperRAM 后 latency 值适配实操
经验分享 | STM32H743 BDMA+LPTIM+LPUART应用演示
经验分享 | STM32H7Sx MCE 加密解密:外部存储安全防护全解析
如何在STM32和Arduino上实现卷积神经网络
详解STM32单片机的堆栈
STM32 开发者指南:ST.com 全新 MCU 产品阵容视觉布局深度解析
STM32和Arduino对比,谁更耐打?
微信公众号
手机版