STM32 WWDG 中断在未配置时触发 [英] STM32 WWDG interrupt firing when not configured

问题描述

我有一个应用程序，由于许可证问题，我正在从 Keil IDE 移植该应用程序以使用 GNU 工具链构建该应用程序.我已经能够在设备上成功设置、构建、刷新和运行应用程序.

I have an application that I am porting from the Keil IDE to build with the GNU toolchain due to license issues. I have successfully be able to set up, build, flash and run the application on the device.

GNU 端的应用程序由于某种原因陷入了 WWDG 的弱链接 IRQ 处理程序，这是一个无限循环.应用程序不启用 WWDG，默认情况下它在重置时被禁用.我还验证了配置寄存器的默认启动值.

The application on the GNU side is for some reason is getting stuck in the weak linked IRQ handler for the WWDG which is an infinite loop. The application does not enable the WWDG, and it is disabled at reset by default. I have also verified that the configuration registers are at their default startup values.

除了编译器之外，唯一的区别是链接器和启动文件.但是，两个工具链使用的启动文件和链接器文件都是 STM 生成的默认值.

The only difference, other than compilers, are the linker and startup files. However, both the startup files, and linker files used by both toolchains are defaults generated by STM.

知道是什么原因造成的吗?到这里我就快没脑子了.

Any idea what may be causing this? I'm about at my wits end here.

使用 stm32f103XX，让我知道是否有任何其他信息会有所帮助.

Using the stm32f103XX, let me know if any other information would be helpful.

使用下面的评论，我能够确定它实际上是被触发的 HardFault_Handler.如果可能有帮助，我已经在下面包含了回溯输出

Using the comments below I was able to ascertain that it is, in fact, the HardFault_Handler that is being triggered. I have included the backtrace output below if that may be of help

GDB BT:

0 HardFault_Handler()

0 HardFault_Handler ()

1(调用的信号处理程序)

1 (signal handler called)

2 0x720a3de 在 ??()

2 0x720a3de in ?? ()

3 0x80005534 in foo()

3 0x80005534 in foo ()

回溯停止:前一帧与此帧相同(堆栈损坏?)

Backtrace stopped: previous frame identical to this frame (corrupt stack?)

有两件事对我来说很突出，尽管我不是 gdb 专家.1) foo 不是函数，它是一个常量字符数组 2) 0x0720a3de 不是有效的内存地址，闪存地址范围从 0x08000000 开始

2 things stand out to me, though im no gdb expert. 1) foo is not a function, it is a const array of chars and 2) 0x0720a3de is not a valid memory address the flash address range starts at 0x08000000

推荐答案

感谢 D Krueger 的大力支持.我能够弄清楚 HardFault_Handler 是实际被调用的.所以，任何偶然发现这篇文章的人，通过编写临时函数来覆盖可能的罪魁祸首，即 HardFault，验证哪个 IRQ 真正被调用.IRQ 调用的真正问题是 memcpy 的内存访问错误，我正在解决接下来的问题.

So thanks to the kick in the pants by D Krueger. I was able to figure out that the HardFault_Handler was what was actually being called. So, anyone that stumbles on this post, verify which IRQ is truly being called by writing temporary functions to cover the likely culprits i.e. HardFault. The true issue for the IRQ call is a bad memory access by memcpy which I am on my way to solving next.

这篇关于STM32 WWDG 中断在未配置时触发的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！