Skip to main content
M
MichaelR91
Visitor II
January 7, 2026
Question

STM32MP157C - iwdg1 reset during programming via USB

  • January 7, 2026
  • 1 reply
  • 68 views

Hello!

I am in the progress of setting up a Yocto based build for a custom board based on a STM32MP157C. I am using "vanilla" Yocto scarthgap with the respective ST meta layer: https://github.com/STMicroelectronics/meta-st-stm32mp meaning I created a custom machine and am patching my own device trees into the meta-st-stm32mp layer.

Currently I am trying to port my device trees for TF-A , OPTEE, U-Bboot and Linux, that were originally created for an SDK based build, to the new environment. I am using the regular "optee" bootscheme in my custom maschine.conf with EMMC as boot device.

The build already succeeds but when I try to program the contents of my .tsv via Cube32Programmer I get a "iwdg1" reset when the bootfs is downloaded:

UPLOAD ... done
Ctrl+C to exit ...
#DOWNLOAD ... OK
Ctrl+C to exit ...
#
UPLOAD ... done
Ctrl+C to exit ...
#
UPLOAD ... done
Ctrl+C to exit ...
###D/TC:0 gic_native_itr_handler:678 Special interrupt 1023
D/TC:0 gic_native_itr_handler:678 Special interrupt 1023
D/TC:0 stm32_iwdg_it_handler:196 CPU 0 IT Watchdog 0x5c003000
E/TC:0 Panic 'Watchdog' at /usr/src/debug/optee-os-stm32mp/4.0.0-stm32mp-r2/core/drivers/stm32_iwdg.c:218 <stm32_iwdg_it_handler>

Regarding the watchdog configuration in the device trees I have stuck to the examples e.g. "stm32mp157c-ed1.dts".

So I am using "iwdg1" in OPTEE and TF-A.

 

&etzpc{
	status = "okay";
	st,decprot = <
	...
	DECPROT(STM32MP1_ETZPC_IWDG1_ID, DECPROT_S_RW, DECPROT_LOCK)
	...
	>;
};

...

&iwdg1{
	status = "okay";
	timeout-sec = <32>;
};

In U-Boot I am using "iwdg2":

&iwdg2{
	status = "okay";
	timeout-sec = <32>;
};

I could already narrow the issue down a little bit, when I disable "iwdg1" in the TF-A device tree only (and keep it enabled in the OPTEE device tree), the programming works as expected and my Yocto Linux boots.

Unfortunately, I am now stuck and am not sure how to further debug this issue.

Which software component is responsible to service "iwdg1" during programming?

Is my understanding correct that in this case OPTEE/TF-A should service "iwdg1" autonomously without any user action required?

Why could the issue gone when disable "iwdg1" in TF-A only?

 

Thank you so much,

Michael

 

      This topic has been closed for replies.

      1 reply

      M
      MichaelR91Author
      Visitor II
      January 8, 2026

      I have an update to my issue: I dug into the source code of optee and it looks like the secure "iwdg1" needs to be triggered via SMC interface by U-Boot / Linux. After further digging into it, I saw the the U-Boot / Linux device tree needs to include arm_wdt to auto-trigger the "iwdg1" via the SMC interface.

      /* For U-Boot and Linux dts */
&arm_wdt {
	timeout-sec = <32>;
	status = "okay";
};

      Is this the indented way of operation? Should "iwdg1" be serviced this way? I am curious how the device trees have worked in our old implementation since there the TF-A / OPTEE dts had only configured "iwdg1" and U-Boot / Linux dts had only "iwdg2" configured. So U-Boot / Linux did not trigger "iwdg1" via SMC (arm_wdt) - still the old implementation worked on the SDK based build.

      Terms & ConditionsAccessibility statement