STM32F030, stopping the IWDG

[CharlieMangold]

Posted on January 06, 2017 at 15:12

We have a project that is required to go through UL testing, so it needs both a watchdog and a check that the processor frequency is running as expected. Because the independent watchdog uses its own oscillator it seems to be a perfect fit for doing both. The problem is that when a severe error have been detected, we need to go into a safe shutdown, turning off all interrupts.

We have

read through the reference manual and have found the sequence

to get the IWDG running and how to reload, but nothing about stopping it. There

is a sentence in paragraph 19.3.1 of the reference manual that says:

'Whenever the key value 0x0000 AAAA is written in the IWDG_KR register, the IWDG_RLR value is reloaded in the counter and the watchdog reset is prevented.'

       Is this the same as disabling the independent watchdog

window or is there any other method of stopping it?

Thanks,

     John C.

[Tesla DeLorean]

Posted on January 06, 2017 at 17:00

You can't stop it, only kick it. What you've quoted is the kicking of it back to whatever maximal value you initially selected, and you'd need to keep doing that every time before it expires to stop it resetting the chip.

You can use DBGMCU settings to stall it during breakpoint/debugging.

[CharlieMangold]

Posted on January 06, 2017 at 17:37

I was hoping there was some super secret way of stopping it because in my current shutdown function I have to track time by reading the sysTick to keep kicking the IWDG in the proper time frame. Even the WWDG has no documented way of stopping it and I don't see a way to run it as plain watchdog.

John C.

[AvaTar]

Posted on January 06, 2017 at 17:20

Just as a comment - this 'unstoppability' is by design. And this is supposed to be a safety feature.

If you can't, neither an application going wild can.

[CharlieMangold]

Posted on January 06, 2017 at 17:50

I guess I don't agree with this design. Having register 'key' values that must be written in specific sequences is a pretty robust way of keeping bad software from wreaking havoc. By making this 'unstoppable', the design has placed a requirement on software that no matter what, severe error or not, you must keep track of time. So with this processor and other variants there is no such thing a small while forever loop for software to die in. I guess you could specifically cause the watchdog to expire, wait for the reset to occur and trap it on the way up. But doing this means you need to have some memory somewhere to store error codes so you can figure out what the true original error was as you boot back up.  

[AvaTar]

Posted on January 07, 2017 at 12:48

All implementations I know work that way (of course not only ST's).

And the people from safety software certification institutions will tell you that wild-running code will erraneously execute that watchdog stop routine, and doing even worse things later on (my company has discussions with such people sometimes...).

I guess you could specifically cause the watchdog to expire, wait for the reset to occur and trap it on the way up. But doing this means you need to have some memory somewhere to store error codes so you can figure out what the true original error was as you boot back up.

You are supposed to remove all bugs before releasing the SW.

Otherwise (unexpected state, or known state that cannot handled by SW alone), the system is supposed to assume a safe state. Just imagine the MCU controls a machine weighting several tons, is handling heavy weights, or reaches 50 ... 100mph.

We store only machine-related errors, which are more interesting for users/customers.

In case of an internal error (SW trap, fault handler) one usually can't assume an uncompromised permanent storage either.

[CharlieMangold]

Posted on January 09, 2017 at 15:22

The point I think you are missing is that error conditions other than the watchdog can occur and what do you do if they are detected. CRC errors on you code, ram check failures, processor register failures...All of these are severe errors and means you need to put your system into a safe condition and not leave. This usually means some style of shutdown function/condition. The inability to stop the watchdog which serves no use in a shutdown function does not seem to make sense. Now if ST had put a way in the hardware/CPU to handle severe error conditions then I would not complain.

[S.Ma]

Posted on January 07, 2017 at 16:08

A watchdog exists to prevent the code turns haywire for too long from any SW or HW reason.

When the code is running unknown op-codes, the watchdog is the last resort to stop it (probably a wrong memory access would kick in first).

What happens if the core bumps into a HALT op-code which stops the code and its clock?

Normal watchdog could freeze and never trigger a reset. So the introduction of the independent oscillator watchdog.

What would happen if the core could execute a 'hidden' sequence that stops the analog watchdog? [....]

Remains the probability to execute a

while(1) { kick-in the watchdog }

  This code should exist in a single place (and called from single point if possible) and wrapped by 'returns' to lower the probabilities to be near perfect.

Filling unused flash area with op-codes to cause a reset might also be contenplated.

Make sense?

Good luck!

PS: Equally challenging is ESD discharge on remote devices accessed by serial bus which register setting may be corrupted...

PS2: There are techniques to detect at the beginning of user code if a watchdog reset occured of not, so it is possible to breakpoint on such event.

[CharlieMangold]

Posted on January 09, 2017 at 17:06

Watchdogs are a great thing, but when other severe errors are detected and you need to stop everything, you should be able to. If your ram test fails, is it really necessary to be running a watchdog when you go into shutdown? To be honest I'd rather see the processor have some type of safe mode when software detects problems, but then I would be requiring some hardware capability. My only point is that when ST decided to not allow windowed watchdogs to be stopped, then they placed a requirement on software to track time correctly because you can't kick the windowed watchdog anytime you like. I would also have been ok with a software configuration to take out the window function so the software could simply kick the watchdog at any point in shutdown. I simply like it better when hardware does not force software to behave in certain ways.

[Jeroen3]

Posted on January 08, 2017 at 15:59

'The problem is that when a severe error have been detected, we need to go into a safe shutdown, turning off all interrupts.'

I don't see the issue. You simply force a reset of the iwdg (prescaler and reload to 0). Then you look at the reset flags, and anything that isn't normal means you enter your safe shutdown.

[CharlieMangold]

Posted on January 09, 2017 at 17:16

My only issue is that when the reset occurs and you see a watchdog reset has occurred, that is not the real reason the system has gone down. You will need to store some type of error code in ram/flash so that when the reset has been detected, you need to verify what the real reason was for the reset error. Maybe it was that you detected a CRC error in your executable, hit the shutdown function and then the watchdog expired. Is it really that hard to do? No, not really. In my opinion it is just a case of processor hardware forcing the issue. Would it really been that hard to have some flexibility with the watchdog operation?