STM32Cube SystemClock_Config() init code generating WWDG interrupt but WWDG is not enabled.

dean · ‎2016-01-15

Posted on January 15, 2016 at 18:27

Hi all, I'm still relatively new to the Arm Core M3 processor, and trying to get a device up and running using the STM32CubeMX tool compiling with the Atollic Truestudio Lite dev system. The device I am programming is a STM32L151RETx with the only enabled features bing the SPI, I2C, and several gpio pins, and using a 16 MHz HSE clock source. I originally wanted to have the busses run at 32 MHz so I used to STM32CubeMX tool to direct the HSE clk through the PWM multiplier circuit to generate the 32 MHz bus clocks, but we found this led to inaccurate clock period due to extreme temperature variations (faster at very cold temps, slower at very hot temps), while the 16 MHz clock remained rock solid, so we decided to forego using the PWM multiplier circuit and use the HSE clock source to drive the bus clocks directly, even if half as fast as they can go.

I used the STM32CubeMX to generate this new startup code with the change to the clock configuration (System Clock Mux set to HSE) , and the new project builds fine, but when loaded onto our device, it generates an exception during the SystemClock_Config() function call in main(). The exception handler called is the WWDG_IRQHandler() but the WWDG is not enable in our project.

I have attached a screen capture of the resultant exception showing the stack trace using the Truestudio debugger.

I am suspecting the STM32CubeMX code is incorrectly enabling the WWDG interrupt, but I am not able spot this yet. But it is troublesome if this is how the STM32CubeMX code works unaltered.

Am I simply overlooking something in the System Clock Configuration or is this a known bug in the STM32CubeMX code generation? If a bug, what is the proper fix please?

Thanks in advance for any helpful ideas!

dean · ‎2016-01-21

Posted on January 21, 2016 at 17:41

Hello all,

Just letting those following this issue that I was successfully able to determine the cause of the unhandled interrupt that was causing my device to fail during systemclock_config().

When I ported my code onto a Nucleo development board, the initialization code worked fine with the HSE clock driving the system and bus clocks directly. It was only when running on our device that the unhandled interrupt would occur.

Consulting with my hardware engineer, we discovered that the HSE clock configuration was incorrectly set to ''Crystal/Ceramic Resonator'', when in fact we are supplying an HSE clock signal directly so it should be set to BYPASS Clock Source.

This was incorrectly set even when the HSE was driving the PLL Source Mux, but it wasn't causing an interrupt in this configuration. We still don't understand why it lived in that configuration but not in the other, but it was a good lesson learned of what happens when you set this configuration incorrectly.

This was a very simple configuration mistake that ''looked'' correct, but was a real head scratcher and really shows how important even the minutest details can adversely affect your system.