有人使用STM32芯片从事产品开发，代码中有涉及到除以0操作。他们发现基于相同的代码，使用不同IDE会出现不同结果。在IAR或ARM MDK环境下除以0操作所得结果为0，而在STM32CubeIDE环境下的运行时则产生HardFault异常。他们对这个结果感觉很奇怪，甚至怀疑是不是CubeIDE环境有bug。

根据ARM内核相关手册描述，关于除以0事件或非对齐访问事件是否进行捕捉并触发异常是可以配置的。如下图所示：

其中，除以0事件由内核的配置控制寄存器CCR的DIV_0_TRP控制。该位清0时，系统不对除以0事件触发异常，结合下面截图描述得知，此时硬性返回0值作为结果。

也就是说，只有控制位配置为1并发生除以0事件时才触发异常。另外，上图最后一句明确说明，复位后该位值为0.

结合客户的描述，感觉在ARM MDK和IAR环境下，该位默认值或者说复位值为0，而STM32CubeIDE环境下该位复位默认值则为1。这似乎有点说不通。因为这个默认复位值应该是跟着内核芯片走，不会跟着开发环境走。【用户代码一样】

我随手找个STM32开放板，先基于IAR环境做了个测试。在测试代码里制造了除以0事件，的确没有触发异常，而且还返回了结果0。查看IAR开发环境下了SCB->CCR->DIV_0_TRP控制位，如下图所示，其值为0。结合内核资料描述，这点跟测试结果吻合。

我尝试将该控制位改为1后再运行除以0代码，立即触发异常。如下图所示：

当我将测试代码转到CubeIDE去调试，也马上触发异常，并明确提示发生除以0事件。

顺便在SFR寄存器里查看SCB->CCR->DIV_0_TRP位的值，果真是1，见下图：

我在用户代码里并未对该控制位进行改写，按理其复位值应该是0。难道哪里改写它了？

我尝试到STM32CubeIDE的用户手册UM2609找找，看看能否找到相关信息。在里面搜索DIV_0还真找到相关信息了。

这里的文字表明，调试状态下关于除以0事件的异常捕获是默认使能的，目的是为了帮助用户在调试时及时发现除以0异常。这个说法没毛病，问题是在哪里对其使能置位的呢？ARM内核复位后可是清零了的。

继续查找相关信息，看到了该段文字上方有个截图，如下图所示：

从上图可以看出，关于除以0操作或非对齐访问是否触发异常，这里可以选择配置。在STM32CubeIDE调试状态下，除以0操作的异常捕获默认被使能，基于该配置并在工程启动时借助调试部件修改了相关寄存器。

当我把这个地方取消勾选后，使用前面相同代码做验证调试，此时不再触发异常并返回0值结果。到此，也就解释了发生除以0操作时，为什么STM32CubeIDE会出现与MDK、IAR不同的调试结果。

显然，STM32CubeIDE默认调试状态下使能除以0事件的捕获，这样的确便于我们在调试时就能及时发现除以0事件，若是不该出现的，赶紧查错纠错，避免其发生。如果是允许出现的特别应用场景，调试时可以通过CubeIDE配置关闭其异常捕获。

相比其它IDE，STM32CubeIDE在这个地方显得更为方便些。我们只需基于调试环境做简单的勾选即完成修改，每次程序启动时即生效，在IAR、ARM MDK环境下往往需要事先添加用户代码修改SCB->CCR寄存器内容。

讲到这里，我要特别提醒下，对于除以0事件或对齐事件的捕获与否，最终取决于用户代码。

STM32CubeIDE只是在调试状态下根据配置修改了相关控制寄存器位，不等于用户代码对其做了修改。

前面提过，除以0事件相关寄存器控制位复位后默认值为0，即默认不触发除以0异常。如果说CubeIDE的调试配置跟其芯片复位后默认值一致倒没什么，如果CubeIDE里的调试配置是使能除以0异常的捕获，而在用户代码里却没有相应实现代码，这时代码运行若有除以0事件，调试时自然可以发现，但全速运行时还是不会触发异常【此时代码运行脱离了调试组件】。所以，要保证全速运行时也能对除以0事件进行异常捕获，我们终究还得在用户代码里对SCB->CCR寄存器的DIV_0_TRP位进行置位。

STM32CubeIDE这里的调试配置为我们提供了方便，同时个人认为其默认的调试配置也是合理的，毕竟并非所有人都知道芯片复位后默认除以0事件不触发异常，当然，一般来讲编译时会有警告。