ESP32 How to reset watchdog timer (WDT)

[stefan.erni]

Hi to All

With Flowcode, you usually have to add a delay of a few milliseconds into a loop to reset the WDT.
However, this is not always possible or practical.
There is another option: using a WDT reset.

But I can not compile if,

I include
#include "esp_task_wdt.h"
and.
esp_task_wdt_init(5, true); // Timeout 5 Sec autoReset = true
esp_task_wdt_add(NULL); // NULL = aktual Task ( loop-Task)

2025-08-08_16-04-48.PNG (21.44 KiB) Viewed 5322 times

and in the main:

2025-08-08_16-10-24.PNG (8.57 KiB) Viewed 5322 times

Testprogram:

Post_wdt1.fcfx

(12.37 KiB) Downloaded 372 times

[mnfisher]

It was possible with v4 of the espressif tools - I posted a 'feedthedog' somewhere here.

But - it no longer works and is much frowned upon now (see https://docs.espressif.com/projects/esp ... /wdts.html) - as it will cause things to break. I haven't managed to find a workaround in v5.

It should be possible to re-factor your code to avoid the need to do it. Use timers and separate tasks to do the time critical stuff and the main loop can just include a delay. However all tasks MUST yield either with a delay or a Wait for semaphore / Msg etc in < wdt interval - to keep RTOS happy.

Martin

[stefan.erni]

Hi Martin

I found the old way...
and I can include now but not yet reset the wdt in a c-code in the main loop

supplementery code
#include "rtc_wdt.h"

in main begin:

Code: Select all

esp_task_wdt_init(5);        //  Timeout set
esp_task_wdt_add(NULL);      //add Task

Yes it is different
ESP-IDF-Version
ESP-IDF Version Functions-Signatur
IDF v4.1 and older esp_err_t esp_task_wdt_init(int timeout_seconds, bool panic); (2 Argumente)
IDF v4.2 and new esp_err_t esp_task_wdt_init(int timeout_seconds, bool panic, bool feed_task, bool idle_task); or esp_err_t esp_task_wdt_init(int timeout_seconds, bool panic); (depend API)
IDF v5.x esp_err_t esp_task_wdt_init(int timeout_seconds, bool panic); (again 2 Argumente)

[mnfisher]

In the task (using NULL in task_wdt_add uses the current task) can you use

#include <esp_task_wdt.h> (in supplementary code)

esp_task_wdt_reset(); (in task)

Which would need to be called at 'intervals' of < wdt timeout.

Martin

[stefan.erni]

Hi Martin

Thanks for the help. I can now reset the WDT in the main.
In the main on start it's working just with this "Null". If I use "main" or "FCM_main" it' not compilling

to reset, it need a command more with vtaskDelay(1):

Code: Select all

esp_task_wdt_reset();
vTaskDelay(1);

I can set the time to reset, using a timer, so I have every one second a reset wdt;
I reset the WDT in the main program.

reset in main:

Post_wdt3.fcfx

(13.63 KiB) Downloaded 297 times

2025-08-11_11-19-21.PNG (3.58 KiB) Viewed 5170 times

However, I still need to reset a wdt in a created task. Once in core0 and once in core1.

[mnfisher]

I think you would use the task_id returned by xTaskCreatePinnedToCore in task_wdt_add or call task_wdt_add(NULL); in the task itself (before it starts loop)

Martin

[stefan.erni]

Hi Martin

A Delay less than 10mSec does not reset the WDT!

I testet the commands for reset WDT that work.

This Both command .

1. Delay 10mSec is clear, it makes a 10mSec break(where can cause problems)

2. vTaskDelay(1); it makes a 6.5mSec break(where can cause problems) in C-Code

vTaskDelay(1);
But if I change Config TICK rate HZ from 100 to 1000, vTaskDelay(1); makes just a 0.4mSec break ,

2025-08-13_11-22-10.PNG (94.9 KiB) Viewed 5112 times

Test result:

2025-08-13_14-27-23.PNG (106.32 KiB) Viewed 5112 times

Testsoftware:

2025-08-13_14-20-25.PNG (29.06 KiB) Viewed 5112 times

I tested the Config standard setting 5 Sec for wtd timeout:

2025-08-13_10-38-54.PNG (258.44 KiB) Viewed 5112 times

And if I not reset a have a timeout after 5Sec

2025-08-13_10-46-54.PNG (70.83 KiB) Viewed 5112 times

[mnfisher]

I did a small Flowchart - showing both ways to do esp_task_wdt_add - and adding two tasks one on core 0 and one pinned to core 1. Both these tasks (which are the same here) toggle a pin (set in properties as pin 0 and pin 1) and reset the wdt every 500000 loops (there is no scientific basis for this number however)

The main task just prints alive every 1s.

What I don't understand is how the main 'loop' continues to function - if core 0 and core 1 and locked into a loop - neither of the sub tasks use a delay or do anything that gives a context switch (unless wdt_reset does - which is the only candidate here!) Looking at the traces - both pins toggle with a 10ms delay every ~10ms (this corresponds to the RTOS tick time) - so although it is killing the wdt it isn't actually stopping the multitasking occurring. (So wdt_reset does a 'yield'?)

I should state - that this probably isn't a good idea and refactoring the code to play nicely together is going to be a better bet. Things like BT / WiFi may well stop working if the user blocks for too long...

Martin

[MJU20]

I've read all the suggestions provided so far, and they are very valuable. However, through Gemini, I came across the following trick that allows me to use delays without triggering my WDT (Watchdog Timer), even when using delays of 500ms or longer.

It might not be the universal solution for every complex case, but during my initial tests with an ESP32-C6, I was getting quite frustrated because the WDT kept interfering and rebooting the chip. I decided to start fresh with a simple program and followed Gemini's suggestion. I’m happy to report that I now have a proud ESP32-C6 blinking an LED right next to me!

The suggestion and explanation from Gemini:

"If an ESP32 reboots because its WDT is triggered, you can solve this by adding a

Code: Select all

vTaskDelay(1);

(via a C-code block) into your main loop. This gives the underlying FreeRTOS operating system the time to execute its maintenance routines and the 'IDLE task', which automatically resets the Watchdog Timer. Without this 'breathing room', a tight loop or a blocking delay can starve the processor of the time it needs for background tasks, leading the Watchdog to assume the system has crashed and force a reboot."[/i]

vdelay1.png (36.98 KiB) Viewed 98 times

Hopefully, this helps anyone else struggling with unexpected reboots on the ESP32 platform!

[mnfisher]

Hi,

Something odd going on if you are getting wdt issues - as you have flowcode delays in your code of 500 ms - using a delay block allows RTOS to context switch..

It is possible to reset the wdt - there is some code on the forum depending on which version of the espressif tools (feedthedog) or esp_task_wdt_reset() BUT it is not recommended - RTOS has multitasking and it expects tasks to yield to allow this. So ideally re-factor your code to allow this - there are alternatives to delays (waiting for notifications for example)

Martin