Yes. I've read that. I can't make heads or tails of it. For example:
By default, the task watchdog watches the idle tasks.
Does this mean it's also fed by idle tasks? what's an 'Idle task'? one that's called vTaskDelay?
The usual cause of idle tasks not feeding the watchdog is a higher-priority process looping without yielding to the lower-priority processes, and can be an indicator of badly-written code that spinloops on a peripheral or a task that is stuck in an infinite loop.
How does a task Yield to another? why would a HIGHER priority task yield to a LOWER priority task? This happened when I only had 2 tasks as well. With 2 cores, this should never happen, no? what are the idle tasks actually feeding the watchdogs? The two loops are using I2c. is this indicative of a non-responsive device?
Other task can elect to be watched by the task watchdog by calling esp_task_wdt_feed(). Calling this routine for the first time will register the task to the task watchdog; calling it subsequent times will feed the watchdog. If a task does not want to be watched anymore (e.g. because it is finished and will call vTaskDelete() on itself), it needs to call esp_task_wdt_delete().
So a watched task must feed the dog, but an unwatched task doesn't? what happens when the dog would normally throw a fit?
The task watchdog is built around the hardware watchdog in timer group 0.
This is the processor clock, right?
If this watchdog for some reason cannot execute the interrupt handler that prints the task data (e.g. because IRAM is overwritten by garbage or interrupts are disabled entirely) it will hard-reset the SOC.
so a dead watchdog makes the software reset?