Flowcode Support Board

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) and in the main:
Testprogram:

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

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:
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)

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

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): 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: However, I still need to reset a wdt in a created task. Once in core0 and once in core1.

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

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 ,




Test result: Testsoftware: I tested the Config standard setting 5 Sec for wtd timeout:
And if I not reset a have a timeout after 5Sec

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