STM32H7 ES0445 2.3.1 watchdog reset scope on CubeOrangePlus / H7 targets

[theodosis_plane (Todo)]

STM32H7 watchdog reset scope / ES0445 2.3.1 feedback request

Hi all,

I would like feedback from the ArduPilot team on an STM32H7 watchdog-reset-scope erratum and a proposed mitigation in the ChibiOS HAL watchdog path.

Context

While reviewing CubeOrangePlus / STM32H757 errata applicability, I found the following STM32H7 erratum:

ES0445 2.3.1 — AXI domain locked when watchdog reset limited to CPU1 or CPU2

The AXI domain may get locked when the watchdog reset is limited to CPU1 or CPU2, i.e. when WW1RSC or WW2RSC is cleared in RCC_GCR, and a watchdog reset is generated.

ST’s workaround is to configure watchdog reset scope to reset the full system by setting RCC_GCR.WW1RSC and/or RCC_GCR.WW2RSC.

For CubeOrangePlus, the firmware target is STM32H757-based (MCU STM32H7xx STM32H757xx). The ArduPilot watchdog implementation directly enables the independent watchdog in:

libraries/AP_HAL_ChibiOS/hwdef/common/watchdog.c
stm32_watchdog_init()

Runtime J-Link inspection on the current target showed:

RCC_GCR = 0x00000000
WW1RSC = 0
WW2RSC = 0

This means an IWDG1 reset is scoped to CPU1 rather than the full system, matching the erratum trigger condition.

Why I think this matters

The question is not whether ArduPilot wants a “larger reset” in normal operation. The issue is that the silicon erratum says a CPU-local watchdog reset can leave the AXI/shared domain locked. In that case, limiting the reset to CPU1 may be less safe than a full-system reset, because the watchdog may not recover the full SoC cleanly.

For an autopilot, my assumption is that if the independent watchdog fires, the safer behavior is full SoC recovery rather than a CPU1-only recovery that may leave shared infrastructure in an undefined or locked state.

Proposed mitigation

Set the STM32H7 watchdog reset-scope bits before enabling IWDG:

#if defined(STM32H7)
#define RCC_GCR_REG (*(__IO uint32_t *)(RCC_BASE + 0x10))
#define RCC_GCR_WW1RSC (1U<<0)
#define RCC_GCR_WW2RSC (1U<<1)
#endif

#if defined(STM32H7)
static void stm32_watchdog_configure_reset_scope(void)
{
    RCC_GCR_REG |= RCC_GCR_WW1RSC | RCC_GCR_WW2RSC;
}
#endif

void stm32_watchdog_init(void)
{
#if defined(STM32H7)
    stm32_watchdog_configure_reset_scope();
#endif

    IWDGD.KR = 0x5555;
    IWDGD.PR = 3;
    IWDGD.RLR = STM32_WDG_TIMEOUT_MS - 1;
    IWDGD.KR = 0xCCCC;
    watchdog_enabled = true;
}

WW1RSC is required for the CPU1/IWDG1 reset-scope case. I also set WW2RSC defensively for dual-core H7 coverage, even if ArduPilot is only running on CPU1 for the reviewed target.

Questions for maintainers

1. Does the team agree that on STM32H7 targets, an ArduPilot independent watchdog reset should reset the full system rather than only CPU1/CPU2?
2. Are there any H7 boards or bootloader/application flows where setting WW1RSC | WW2RSC before enabling IWDG would be undesirable?
3. Should this be applied globally for all STM32H7 ChibiOS builds, or should it be board-gated for affected dual-core parts such as STM32H747/H757?
4. Is there a preferred CMSIS/ChibiOS register definition already available for RCC_GCR and these bits, instead of defining the register offset locally in watchdog.c?
5. Would maintainers prefer the reset-scope bits to be set earlier in board startup rather than in stm32_watchdog_init()?

Evidence checked so far

• CubeOrangePlus hwdef selects STM32H757.
• ArduPilot watchdog code directly programs and starts IWDG in watchdog.c.
• A repo search found no existing RCC_GCR, WW1RSC, or WW2RSC configuration.
• Runtime J-Link inspection showed RCC_GCR = 0x00000000 before this change.

Requested feedback

Please sanity-check the interpretation of ES0445 2.3.1 and whether the proposed mitigation is appropriate for ArduPilot H7 targets. In particular, feedback from maintainers familiar with ChibiOS startup, STM32H7 dual-core behavior, CubeOrangePlus, and watchdog/reboot semantics would be very helpful.

Thanks in advance,
Theo

[Yuri_Rage]

Did you do any human review of this?

I didn’t read past the first few sentences, including a direct AI copy paste of “DRAFT.”

If you wish to get any traction on this topic, please review it and post a human written follow up with your findings. No one wants to interact with this type of generated subject matter.

[theodosis_plane (Todo)]

Hi Yuri and thanks for the feedback. I understand the original post was too long and thus I didnt spent time moderating / reading thorugh it. My actual finding is much simpler - and originates from the errata sheet st published (https://www.st.com/resource/en/errata_sheet/es0445-stm32h745xig-stm32h755xi-stm32h747xig-stm32h757xi-device-errata-stmicroelectronics.pdf):

In section 2.3.1, ST states that a watchdog reset limited to CPU1 or CPU2 can leave the AXI domain locked. Their workaround is to set the watchdog reset scope so that the watchdog resets the full system. Only Independent Watchdog is being used for the H757 with the Window one not being currently used.

On my CubeOrangePlus target, I checked the RCC_GCR with J-Link and found:

• RCC_GCR = 0X00000000
• WW1RSC = 0
• WW2RSC = 0

ArduPilot enables IWDG1 in libraries/AP_HAL_ChibiOS/hwdef/common/watchdog.c, but I could not find anywhere that WW1RSC is set first.

My concern is therefore that, on an STM32H757, an ArduPilot watchdog event may currently generate only a CPU1 reset, which is the condition described by the erratum. The practical mitigation appears to be setting RCC_GCR.WW1RSC before starting IWDG1 so that the watchdog performs a full-system reset.

Before preparing a patch, I would appreciate confirmation on two points:

1. Is my interpretation of the current ArduPilot watchdog behavior correct?

2. Would setting WW1RSC in the STM32H7 watchdog initialization path be acceptable, or is the reset scope intentionally left CPU-local for some boards?

I am mainly looking for a sanity check from someone familiar with the STM32H7 ChibiOS startup and watchdog implementation.
Again excuse me for the original post of mine. In case I would be more helpful in the analysis feel free to provide some feedback on what exactly would you expect.

Best regards,
Theo