STM32 interrupt WWDG interrupt when not configured

Question

I have an application that I am porting from the Keil IDE to build using the GNU toolchain due to license issues. I was successfully able to install, build, flash and run the application on the device.

The GNU side application, for some reason, is stuck in a loosely coupled IRQ handler for WWDG, which is an infinite loop. The application does not include WWDG and is disabled by default when reset. I also checked that the configuration registers have initial default values.

The only differences, apart from compilers, are the build and launch files. However, both the startup files and the linker files used by both tool chains are the default values ​​generated by STM.

Any ideas what might be causing this? I am at the end of my mind here.

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

EDIT: Using the comments below, I was able to verify that this is actually the HardFault_Handler that is starting. I have included traceback output below if this can help

GDB BT:

0 HardFault_Handler ()

1 (signal handler called)

2 0x720a3de in ?? ()

3 0x80005534 in foo ()

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

2 things stand out for me, although I am not a GDB expert. 1) foo is not a function, it is a constant array of characters and 2) 0x0720a3de is not a valid memory address, the range of flash memory addresses starts with 0x08000000

Answer 1

So thanks to the kick in the D Krueger pants. I could understand that HardFault_Handler was what was actually called. So, anyone who stumbles upon this post checks which IRQ is actually triggered by writing temporary functions to cover the likely culprits, i.e. HardFault. The real problem for invoking IRQ is poor memory access with memcpy, which I am on my way to solving the following.

Answer 2

I had exactly the same error as the OP (visible WWDG interrupt, but actually shooting HardFault_Handler) when porting the example for the STM32F3 detection board to compile in CooCox CoIDE 1.7.7 with the STM32Cube F3 libraries (v1.1.0). The code worked fine until I tried to use any interrupts, but as soon as I turned on the SysTick timer interrupt, the HardFault exception worked.

The problem was that I neglected to include the stm32f3xx_it.h and stm32f3xx_it.c files in the project. Their absence did not cause any warnings / errors of the compiler. As soon as they were compiled and linked, the interrupt code went fine.

Answer 3

I had a very similar problem when combining two projects created separately by STM32CubeMX for the STM32F2XX processor. One project used an Ethernet peripheral device, and the other did not. In addition, one difference, the two projects used the same set of peripherals.

After combining the two projects by manually copying the files, the application will end in WWDG_IRQHandler after starting the first task (when interrupts are turned on for the first time). At first I confirmed that the WDGA bit of the WWDG register was not really set, and therefore the WWDG peripheral was turned off. Then I checked that the interrupt vector table was correctly initialized. Finally, after several hours of digging, I realized that I did not define the ETH_IRQHandler function in stm32f2xx_it.c, which caused an Ethernet interrupt, which is handled by the default handler, disguising itself as WWDG_IRQHandler - probably due to optimization.

Answer 4

I had this problem due to the same reason as awilhite . I am using Atollic TrueStudio 8.0.0. I used it to start a project for STM32F030 and (possibly manually) added libraries to the folder with stm32f0xx.h, which defines ADC1_IRQn (IRQ channel number used in the NVIC setup).

And I implemented ADC1_IRQHandler (void) in my main.c (as I used to, and it always worked so far - x_IRQn -> x_IRQHandler)

But after 2 days of frustration, I found out that startup_stm32f0xx.s in my project defines ADC1_COMP_IRQHandler.

So, ultimately, my ADC interrupt handler was undefined, and when the ADC generated the interrupt, the program crashed (WWDG interrupt).

I hope this helps people like me who think they really implemented their handler, but they really didn’t.

Answer 5

I 'll talk a little more about what brought me here, and how I use @Mike's understanding to fix this.

I had a well-functioning project on a demo project in Eclipse SW4STM32, but the sources and headers were scattered everywhere, so I wanted the more “compact” project to be easier to set up and use as the basis for minor changes (and easier to follow in Git )

I created an empty AC6 project designed for the same board. He generated the HAL, startup_stm32.s and LinkerScript.ld . Then I copied all .c and the corresponding .h from the original project to my new project (which in itself was painful because they were scattered across the directories BSP, CMSIS, Components, Middlewares, etc.). Everything compiled and seemed to work until I started a little change.

In the debugger, it seemed that all function calls worked until the main while(1) where I ended up in the Default_Handler defined in startup_stm32.s , apparently from WWDG_IRQHandler . In fact, it was the default IRQ handler for user-defined handlers ( WWDG_IRQHandler was the first to be declared, gdb reported this as this, as @D Krüger pointed out).

Without much luck, I began to study the compiler and linker options or linker script until I realized that the only file that I did not check was startup_stm32.s , which really was different.

I blindly copied it and voila!

The explanation I could give is that STM32 calls the IRQ handlers defined in startup_stm32.s when an interrupt occurs, they all point to Default_Handler() (later overridden by the linker). Therefore, if the .c file you copied defines a handler with a slightly different name (but according to its own startup_xxx.s ), you will end up with the startup_xxx.s Default_Handler() method (which is an infinite loop) instead of the one you defined And that's it goes wrong.

See https://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html for more information.

NB. I am not happy to blindly copy-paste without full understanding, but time limits and milestones usually push you into territories that you are not happy to explore ...

Answer 6

The main problem is that the default handler is called instead of another irq handler. I doubt our situations are the same, but here is my solution:

I was working on a c ++ project, the same thing happened to me. This was the first time I made a project from scratch and using CMSIS. After some unsuccessful attempts, I looked at the generated project when I noticed that in stm32xxxx_it.h prototypes of IRQ handler functions are protected by the following:

 extern "C" { void TIM7_IRQHandler(void); } 

With these guards, the linker could find my own interrupt handler functions.