ARM ST32F400 - a weird problem with the IWDG

[peter-h]

32F417, Cube IDE.

I am using the IWDG watchdog in two possible modes.

One is whether it is set to 1.6 secs (this is to emulate an old Maxim watchdog chip I used for many years) and the retriggered from a 1kHz ISR. Obviously this is not the best way to use a wdg but is better than nothing.

The other is retriggered from application code.

Currently I am testing the 1st one.

I have written quite a bit of code around an RTOS and one of the tasks is processing GPS data arriving at 38k on a serial port. If the wdg is enabled, this task gets stuck, but very rarely. Sometimes in minutes, but usually it runs for some hours. A know a part of this task is still running because it is flashing an LED indicating incoming data. The rest of the task is somehow not running properly, but it is hard to debug because as soon as a breakpoint is hit, the wdog resets the CPU (after 1.6 secs).

After days of messing around, I am speculating that somehow the iwdg is messing with some other CPU feature, perhaps one of the timers. My code uses a lot of timers for packet timeouts, for example.

Putting this in (in the code generated by the ST code generator) makes it work fine, by skipping the iwdg setup



The reload code is this



Has anyone got any bright ideas on how to debug this?

Are there any known issues with the IWDG?

What I could try is to use the IWDG properly and put code in the right places in my RTOS task to retrigger the watchdog But that will just hide the problem, which will manifest itself by periodic restarts.

[AndyC_772]

The first thing I'd do would be to look and see if there's any way to disable the watchdog reset after hitting a breakpoint. I'm not familiar with the Cube IDE, but I find it hard to believe there's not a debugger setting somewhere, given that breakpoints are essentially useless otherwise.

Resetting the watchdog in an ISR really isn't a good idea. If your main code gets stuck in an endless loop, provided interrupts are still ticking away, the watchdog will never trigger a reset and your code remains stuck forever.

A more robust option is to set a flag in your regular ISR, then at various points in your main code, reset the IWDG and clear the flag if (and only if) the flag is set. This ensures the watchdog gets reset only when your code is executing normally and the ISR is also being triggered regularly as it should.

As to why your code is crashing in its current form, is it possible that you're short of stack space? If the ISR calls a HAL function at a time when the stack is already nearly full, that could cause it to overflow.

[errorprone]

The option is located in the debug MCU registers.  In HAL, it is the DBGMCU structure.

[peter-h]

AIUI, the IWDG cannot be disabled once enabled, nor can the period be altered.

Yes of course the 1kHz ISR retrigger is poor practice, but it is better than nothing, and the plan is for any finished and working application to take over the watchdog and do it properly.

[errorprone]

See attached, IWDT can be halted by the debugger if enabled.

[DavidAlfa]

You need to add this line before the main loop:
__HAL_DBGMCU_FREEZE_IWDG();

Also keep an eye on the timers, ex.:
__HAL_DBGMCU_FREEZE_TIM3();


Otherwise they will keep running even if you halt the core while debugging.

[peter-h]

These are brilliant tips - thank you all

Is there no downside to adding these statements in, e.g. for all the timers?

On the original topic, I think the problem was caused by a software issue elsewhere, and nothing to do with the IWDG affecting something.

[DavidAlfa]

These lines stop the peripheral clock when you halt the cpu, that's all.
That's the only thing in stm32 that works as it should

[SiliconWizard]

If I understand correctly, you're clearing the watchod in a timer ISR.
I know you realize it's not ideal, but as an illustration of why this is really poor use of a watchdog, this was actually found in Toyota software a few years ago after a recall:
"Watchdog kicked by a hardware timer service routine"
https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_slides.pdf

[AndyC_772]

That's the only thing in stm32 that works as it should

Care to elaborate? I've been developing for STM32 for years and have only - to my knowledge - come across one erratum that impacted my work.