Ensuring that IWDG running

[mrx23]

On STM32F401 or any STM32,

how can I read back the status of IWDG, ensuring that's it's running, as a safety measure?

As I know direct counter value is not accessible, that would be ideal to see that it's not stuck.

How to detect if LSI (thus IWDG) stopped running?

As I found HAL/registers are mostly write only, not intended to be read back.

Do I need to write this first

IWDG_KEY_ENABLE                 0x0000CCCCu

before

IWDG_KEY_WRITE_ACCESS_ENABLE    0x00005555u

?

// the allowed labels on this website are not really useful/specific enough.

[TDK]

When you boot up, after starting the IWDG, look at reset flags to see if IWDG caused the reset (IWDG_RSTF). If not, then wait until it does.

Note that IWDG has its own clock independent of the common "LSI" clock in the chip. Not sure if this is true or not. The RM suggests it does. CubeMX suggests it doesn't.

Edit: You can update the PR and RLR registers and see that RVU/PVU bits get cleared as a spot-check to see if the IWDG clock is active.

[waclawek.jan]

RCC_CSR.LSIRDY should indicate that LSI is on. In some STM32, LSI is brought in as some timer's channel (e.g. TIM5_CH4 in 'F407), so there its frequency can be observed.

There's probably no direct indication of IWDG running.

Is this attempt to fulfill some regulatory requirement ("functional safety")?

JW

[waclawek.jan]

> The RM suggests it does.

This is consequence of ST poorly handling "integration" (slapping on) of docs of various modules into the whole. While the IWDG chapter, written without the whole in mind for the IWDG specifically, talks about "dedicated low power oscillator"; the RCC chapter has a dedicated "Watchdog clock" subchapter clearly stating that IWDG uses LSI (at least it does in RM0090; I am not bothered to look up the specific 'F401 RM).

JW

[mrx23]

That's my safe mode, when booting up and seeing it was caused by WDT.

Good idea on the update bit, although in order to write I have to unlock the WDT which I think is only possible after it's enabled.

So worst case I could fully reconfigure the WDT when it's time to feed it. But after writing RLR checking for update bits costs nothing, hopefully they don't soon.

It would be great if ST provided more status info, or best the read only counter value to see if it gets stuck.

Or maybe I could turn the LSI into a second WDT, since it's already running.

[TDK · Accepted solution]

Depends what level of paranoia you want to design your system for, or what requirements you're trying to meet. Ensuring LSI is on/ready and checking for IWDG_RSTF once seems sufficient here.

[mrx23]

Yes it's for functional safety.

Looks like it's fed by common LSI, At least I can check that it's value is not stuck.

Big enough problem that the LSI has +-50% tolerance.

[waclawek.jan]

"Functional safety" has little to do with function or safety; it's an administrative requirement. Think of it: the supposed mechanism for "checking" IWDG using software involves several order of magnitudes more possible points of failure than IWDG itself (the whole processor must be running flawlessly, together with a complex bus matrix, FLASH, RAM; the software must be free of errors, etc.). In fact, that's the whole point of watchdog, to have the simplest possible mechanism for recovering from failures, and it's designed accordingly.

It's an administrative requirement without any substance, so the question really isn't whether checking a LSI flag factually ensures IWDG to be running, but whether that check ensures the assessor will be happy while you do as little harm to yourself as possible (every extra line of code is a potential flaw). As it's not a technical thing but an administrative one, so you have to have a "fix" ready for the case of rejection (as it can't be argued rationally); checking the IWDG flag goes away timely may be the plan B here.

JW