WWDG IRQ firing when not confuigured

[marcusdufrane]

Posted on December 22, 2014 at 22:33

I have an application that I am porting from the Kiel IDE to build with the GNU tool chain. The compiled and linked appilcation on the GNU side is crashing and getting stuck in the WWDG_IRQHandler routine, though the WWDG is not currently being used. Can anyone shed some light as to what may be happening here? 

Let me know any other information you may need me to give.The only difference I can think of besides the compiler would be that I needed to use a different linker file, however the one used by the keil compiler is the default provided by STM as is the one Im using for the GNU side.DEVICE: stm32f103 gnu startup file for md devices.

[Tesla DeLorean]

Posted on December 22, 2014 at 22:40

Is it stuck in a tight loop? ie while(1) or ''B .''

It could be all of the weakly defined IRQHandlers which get dumped to a single point, or a Hard Fault Handler. If using C++ (.cpp) be cognizant that the names of the handlers will be mangled by the compiler. Check also the .MAP file.

[marcusdufrane]

Posted on December 22, 2014 at 22:48

Maybe, but im not sure why I would be getting stuck in this particular IRQ.

All the weak linked irqs are defined to Default_Handler which is a loop. So, I put a break point on that function and  ran a back trace when the program broke. It is called from WWDG_IRQHandler.But why would this IRQ be called if I am not enabling it. The datasheet says the WWDG is disabled at reset. and only enabled by software, which I am sure I am not doing...at least not directly. Seeing as this does not happen with the Keil compiler Im at a loss.

[marcusdufrane]

Posted on December 23, 2014 at 17:17

I verified with the debugger that the WWDG configuration registers are set to the default startup values and that they indeed are set to not enable the WWDG. 

What else could possibly be causing this handler to be called?

[Tesla DeLorean]

Posted on December 23, 2014 at 18:37

What else could possibly be causing this handler to be called?

I'd have to look at the .MAP and .ELF to make any real determination. I'd still assume it's some other unhandled interrupt absent some strong evidence otherwise.

...
.text.Default_Handler
0x08006dc0 0x4 out/startup_stm32f401xx.o
0x08006dc0 RTC_Alarm_IRQHandler
0x08006dc0 EXTI2_IRQHandler
0x08006dc0 TIM1_CC_IRQHandler
0x08006dc0 DMA2_Stream5_IRQHandler
0x08006dc0 DMA1_Stream5_IRQHandler
0x08006dc0 PVD_IRQHandler
0x08006dc0 SDIO_IRQHandler
0x08006dc0 TAMP_STAMP_IRQHandler
0x08006dc0 EXTI3_IRQHandler
0x08006dc0 TIM1_UP_TIM10_IRQHandler
0x08006dc0 I2C3_ER_IRQHandler
0x08006dc0 EXTI0_IRQHandler
0x08006dc0 I2C2_EV_IRQHandler
0x08006dc0 DMA1_Stream2_IRQHandler
0x08006dc0 FPU_IRQHandler
0x08006dc0 DMA2_Stream2_IRQHandler
0x08006dc0 SPI1_IRQHandler
0x08006dc0 TIM1_BRK_TIM9_IRQHandler
0x08006dc0 DMA2_Stream3_IRQHandler
0x08006dc0 USART6_IRQHandler
0x08006dc0 DMA2_Stream0_IRQHandler
0x08006dc0 TIM4_IRQHandler
0x08006dc0 I2C1_EV_IRQHandler
0x08006dc0 DMA1_Stream6_IRQHandler
0x08006dc0 DMA1_Stream1_IRQHandler
0x08006dc0 TIM3_IRQHandler
0x08006dc0 RCC_IRQHandler
0x08006dc0 Default_Handler
0x08006dc0 EXTI15_10_IRQHandler
0x08006dc0 ADC_IRQHandler
0x08006dc0 DMA1_Stream7_IRQHandler
0x08006dc0 TIM5_IRQHandler
0x08006dc0 DMA2_Stream7_IRQHandler
0x08006dc0 I2C3_EV_IRQHandler
0x08006dc0 EXTI9_5_IRQHandler
0x08006dc0 RTC_WKUP_IRQHandler
0x08006dc0 SPI2_IRQHandler
0x08006dc0 DMA1_Stream0_IRQHandler
0x08006dc0 EXTI4_IRQHandler
0x08006dc0 WWDG_IRQHandler
0x08006dc0 TIM2_IRQHandler
0x08006dc0 OTG_FS_WKUP_IRQHandler
0x08006dc0 TIM1_TRG_COM_TIM11_IRQHandler
0x08006dc0 EXTI1_IRQHandler
0x08006dc0 USART2_IRQHandler
0x08006dc0 I2C2_ER_IRQHandler
0x08006dc0 DMA2_Stream1_IRQHandler
0x08006dc0 FLASH_IRQHandler
0x08006dc0 DMA2_Stream4_IRQHandler
0x08006dc0 USART1_IRQHandler
0x08006dc0 OTG_FS_IRQHandler
0x08006dc0 SPI3_IRQHandler
0x08006dc0 DMA1_Stream4_IRQHandler
0x08006dc0 I2C1_ER_IRQHandler
0x08006dc0 DMA2_Stream6_IRQHandler
0x08006dc0 DMA1_Stream3_IRQHandler
...