Clarification on IWDG Reset Behavior: UM3150 vs RM0481 (STM32H5 Series)

[shivashankarr]

I came across a discrepancy between two ST documents regarding the behavior of an IWDG reset on STM32H5 devices, and I’d like clarification on what exactly is reset when an IWDG event occurs.

• Document 1: UM3150 Rev 2 – STM32H5 Safety Manual, Table 9 (CPU_SM_6)
  States that the IWDG reset may result in an "incomplete" local safe state — it only resets the CPU and does not guarantee that application software can bring the system to a final safe state. This implies that I/O and peripherals may not be reset. 

• Document 2: RM0481 Rev 2 – STM32H562/63xx Reference Manual, Section 11.3.2
  States that an IWDG event results in a system reset, and all registers (except RCC_RSR and Backup domain) are returned to their reset values, which implies that peripherals and I/O should also reset.

Can ST clarify this apparent contradiction? Does the IWDG event reset only the CPU (as per UM3150), or the entire system including I/Os and peripherals (as per RM0481)?

[KDJEM.1]

Hello @shivashankarr ;

Thank you for bringing this issue to our attention.

I will check this internally and I will get back to you as soon as possible.

Internal ticket number: 213037 (This is an internal tracking number and is not accessible or usable by customers)

Thank you.

Kaouthar

[KDJEM.1]

Hello @shivashankarr;

It mentioned in the Reference Manual the normal behavior, which can be common in several products, not just the STM32H5 family. For further details, the user manual describes the behavior specific to the product. 

The IWDG intervention is able to achieve a potentially “incomplete” local safe state because it can only guarantee that CPU is reset. No guarantee that Application software can be still executed to generate combinations of output signals that might be needed by the external system to achieve the final safe state. If this limitation turn out in a blocking point, End user must adopt CPU_SM_5.  Which may indicate that, in some use cases, it can perform a complete system reset. It depends on the use case of the end user as mentioned in the UM3150.

Thank you.

Kaouthar

[Andrew Neil]

---

@shivashankarr wrote:

• Document 2: RM0481 Rev 2 – STM32H562/63xx Reference Manual, Section 11.3.2
  States that an IWDG event results in a system reset, and all registers (except RCC_RSR and Backup domain) are returned to their reset values

---

In that context, "system" just refers to the STM32 chip.

---

@shivashankarr wrote:

• which implies that peripherals and I/O should also reset.

---

"Reset" as in "returned to their power-on defaults".

But, again, that only applies to the internals of the STM32 chip itself - it won't (necessarily) affect anything external to the chip. Your code would need to manage that.

[shivashankarr]

The concern is UM3150, it states: “it can only guarantee that the CPU is reset. No guarantee that the application software can still be executed.”
In safety-critical systems, this raises a concern — we must ensure a complete reset (including internal peripherals and application domain), not just a CPU core reset.

1. I believe the normal expected IWDG behavior is to complete reset (including internal peripherals and application domain). if the IWDG is configured to trigger a complete reset, is there a chance does it in can only reset the CPU on STM32H5-series?

2. On STM32H5-series, under what conditions does the IWDG trigger only a CPU reset (core-only)?

3. If so, what mechanisms or configuration options are available to guarantee that the IWDG triggers a complete reset (i.e., resets both CPU and application domain), as required for safety-critical applications?

Thank you.

Shiva

[Tesla DeLorean]

Watch things like I2C and QSPI devices lacking an async reset in common with the MCU. These can be left in indeterminate states

[Andrew Neil]

---

@shivashankarr wrote:

The concern is UM3150, it states: “it can only guarantee that the CPU is reset. No guarantee that the application software can still be executed.”

---

But that appears in section 3.6.1, titled "Arm^® Cortex^®-M33 CPU" - so that section is focussed purely on the CPU.

Other sections address other parts of the chip: