
前言 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 的状态。 完整版请查看:附件 |
拷打cubemx【003】——找不到的芯片包
【2025·STM32峰会】GUI解决方案实训分享5-调通板载的NRF24L01 SPI接口并使用模块进行无线通信(发送和接收)
【2025·STM32峰会】GUI解决方案实训分享4-使用MVP架构从硬件外设读取数据并显示到图形界面、从图形界面发送指令控制硬件外设
【2025·STM32峰会】GUI解决方案实训分享3-搭建空白TouchGFX例程并实现简单的功能(含硬件部分的串口打印)
【2025·STM32峰会】GUI解决方案实训分享2-编译运行TouchGFX咖啡机例程(含桌面仿真)
【2025·STM32峰会】+TouchGFX实现动态进度显示以及界面切换
【2025·STM32峰会】+使用TouchGFX快速创建GUI
【2025·STM32峰会】GUI解决方案实训分享1-对LVGL咖啡机例程的牛刀小试以及问题排查
实战经验 | 关于STM32H7使用LL库生成ADC代码工作异常问题说明
实战经验 | 关于STM32H745的MC SDK电机控制工程问题的解决办法