How to turn off the system's watchdog in stm32mp257

[bugman]

hello ST:

     I used the stm32mp257 platform for KGDB debugging and found that it always resets the watchdog.

     I tried to disalbe the relevant nodes in the device tree of the kernel and optee:

      

///kernel：
&arm_wdt {
	/*timeout-sec = <32>;
	status = "okay";*/
	status = "disabled";
};

//Optee:
&iwdg1 {
/*timeout-sec = <32>;
	status = "okay";*/
	status = "disabled";
};

Will it still cause the system to restart after a period of time? How should this be handled?

and this html Open fail~

 

 

 

 

[GatienC]

Hello @bugman ,

If you have TF-A, the one actually starting the watchdog is TF-A.

Disabling this will only prevent the kernel from refreshing the watchdog.

Regarding debugging, the IWDGx downcounter (refer to IWDG chapter first table) can freeze on MP25 platforms when the CPU enters in halt mode if the configuration is correct. Depending on the debug configuration, there are conditions, can you refer to the "IWDG1 behavior in debug" table in the reference manual?

Regards,

Gatien

[bugman]

hello GatienC:

I have three questions:

1. If I remove the watchdog from the device tree in TF-A, will it completely disable IWDGx?

2. Is the debugging method you mentioned KGDB debugging method? I am using the following debugging methods for KGDB:

Enable the following configurations in the .config file:

CONFIG_KGDB=y
CONFIG_KGDB_SERIAL_CONSOLE=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_INFO=y
CONFIG_FRAME_POINTER=y

When I use KGDB for debugging, it seems that the system will not freeze the watchdog.

3. I checked the wiki and didn't know how ST uses GDB and kernel connection for debugging, JTAG ？so I chose KGDB。

Debugging the Linux kernel using the GDB - stm32mpu

Regards

 

[GatienC]

Hello,

1) Yes, it should. TF-A is the only one that can start the watchdog in the latest OSTL releases.

2) It is not dedicated to a particular debugging method, it is how the hardware reacts when the CPU gets halted, depending on the debug configuration. Whether you succeed to halt the CPU with KGDB is KGDB-related. I don't see why you would not be able to do so?

3) What is the missing information in what you have linked? Regarding the kernel debug, are you trying to debug built-in drivers/core or modules? Modules are a lot trickier whether debugging the core/built-in drivers is easier. I personally use GDB + OpenOCD for which there is documentation on the Wiki.

You can also check: STM32_MPU_Platform_trace_and_debug_environment_overview and Trace_and_debug_scenario_-_UART_issue 

 

Regards,

Gatien