1.引言

重新编程烧录了 STM32H7 目标芯片后，我就无法连接到该设备。选择 “Connectunder reset”连接也没有帮助。为什么 ?

2.问题分析

通过日常客户的技术支持整理，有两种可能的根本原因导致这个问题。第一种可能性更大，与电源配置错误有关。其次是 Option Bytes 选项字节中的内核启动配置相关。下面我们来具体地看一看。

2.1 可能原因一（电源配置错误）

这条原因适用于所有具有可配置内部 SMPS 降压转换器的 STM32H7 芯片。采用嵌入式降压转换器的 STM32H7 器件提供了不同的电源方案。代码中供电电源的所选配置取决于外部电源电路组件的连接。此配置只能在上电复位后设置一次。选择错误的配置会导致 MCU锁定，也即是说 STM32H7 软件代码配置的供电模式与外部硬件供电连接的模式不一致不匹配的时候，会导致该芯片被 lock-up 锁定。

软件代码中关于电源模式的配置可以通过 HAL 库中的以下代码行完成(通常放在SystemClock_Config 函数中) :

大多数的电路原理图设计都会选择 SMPS 作为直接 MCU VDD 的供电方式（如果该SMPS 模块在 MCU 中可用），这里就需要使用 PWR_DIRECT_SMPS_SUPPLY 参数替代PWR_LDO_SUPPLY 调用上述函数。但是在早期的 STM32CubeMX 生成的项目在默认情况下可能是 PWR_LDO_SUPPLY 电源选项。所以这儿导致了不一致。而在 CubeMX 5.4.0 及更高版本中提供了 PWR_DIRECT_SMPS_SUPPLY 电源做为默认选项。所以要注意配置的一致性。由于配置只能在上电重置后更改一次，因此问题可能会在下一次电源复位后出现。

下面是参考手册中的图表，显示了电源的不同硬件配置：

MCU 内含保护机制，可防止将更高的电压从内部 SMPS 导入到 VCORE（1.8 或 2.5V）。这样可以防止由于配置错误而损坏 MCU。

由于电源通常在复位后立即配置，因此很难连接。

解决方案 1 是：

1、将复位按钮保持在低位（通常为 NRST 引脚），然后接通将电路板电源；

2、保持复位按钮低；

3、通过 STM32CubeProgrammer 连接。当程序开始连接时松开复位按钮；

4、如果连接不上继续执行上述步骤，如果连接上则执行批量擦除；

5、确保已修复项目中的电源配置，重新下载；

解决方案 2 是：

1、强制将 BOOT0 引脚保持高位，然后上电复位目标板。这需要将 BOOT_CM7_ADD1 设置为系统内存；

2、保持 BOOT0 引脚电平为高；

3、通过 STM32CubeProgrammer 连接。系统引导加载程序 System bootloader 不会使用自己用户的电源配置；

4、执行批量擦除；

5、确保已修复项目中的电源配置，重新下载；

2.2 可能原因二（Cortex-M7 启动已禁用）

这适用于所有具有双核功能的 STM32H7 设备。

有时我们调整选项字节的配置使得只有 Cortex-M4 在复位后才启动（BOOT_CM7/BCM7=0，BOOT_CM4/BCM4=1）。

此时你需要将调试器连接到访问端口 AP=3（CortexM4），而不是访问端口 AP=0（Cortex-M7）。

此处提醒，使用 STM32CubeProgrammer 进行连接时，注意保持 STM32CubeProgrammer 为最新版本。对于开发，建议保持两个内核启动配置，否则有些 IDE 工具可能无法与设备一起工作。

前言

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 的状态。

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

MMC 中断的特点

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

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

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

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

综合这两点，我们可以认为，在长时间以太网收发包之后，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 进行一个读的操作。

以及

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

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 以太网的用户进行调试时参考。