WWDG - max timeout so short?

[s_]

I'd like to use one of the watchdogs on STM32F407, but I'm surprised the maximum timeout of the WWDG is so short (around 50millisecs, depending on clock speed).

This is very restrictive, for example a sector erase takes much longer than this (and is an atomic operation).

(I can't use the IWDG as it keeps running during standby, waking us from low power mode).

Are there any ways round this?

[Danish1]

WWDG is driven off APB1, so it is based on the frequency of PClk1.

The examples in the reference manual show you can get up to 69.91 ms if PClk1 is running at 30 MHz.

If you want it longer than that, you will have to slow APB1.

APB1 is driven off AHB Clock via a programmable divider in RCC_CFGR; you can set it to divide by 16.

And you can also slow AHB, dividing by as much as 512 from sysclk.

You could permanently leave APB1 slow if that does not compromise e.g. baud rates.

Or just slow APB1 and AHB for the duration of the FLASH operations.

Hope this helps,

Danish

[waclawek.jan]

> for example a sector erase takes much longer than this (and is an atomic operation).

You can run code (resetting periodically the watchdog) from RAM during sector erase.

JW

[Piranha · Accepted solution]

> (I can't use the IWDG as it keeps running during standby, waking us from low power mode).

IMHO this was a bad design decision by ST. At least on newer designs such as F7 and L4, it can be disabled by configuring option bytes.

But there is a workaround for older designs also. One can do it similarly how bootloaders do it. Dedicate some RAM location, which is not initialized during startup, for a "magic value". When entering standby mode is necessary, set a magic value and do a system reset. Before the IWDG is started at the beginning of main() or even earlier in a startup process check the magic value. If it is there, put the MCU in standby mode.

[s_]

Thanks Piranha - great idea.

[Tesla DeLorean]

The early STM32 while well executed (lack of errata) have a lot of poor design choices, many due to expediency and simplistic design. The 16-bit timers and counters being particularly egregious in a 32-bit MCU. I can imagine a 32-bit implementation of the current TIM would have been a beast in size/power, other better designs would have kept things simpler and more specialized, ie 32-bit encoders, which don't need to actually clock into the tens of MHz, and NCO/ADDER type clock dividers. Most of the transistors burned on the TIM are completely wasted.

[Piranha]

I would also add 16-bit GPIO ports and the limited design of EXTI for pin interrupts. A 32-bit GPIO with an interrupt handler for each port as on NXP's LPC series is much more flexible and universal design.