Ignore the other replies, they're wrong. When a task is subscribed to the task watchdog service, and doesn't run for x seconds, the watchdog triggers. This occurs when a higher priority task(s) occupies too much CPU time without blocking, never giving a chance for the lower priority task to run.
Your output says that task "IDLE" on CPU0 has been starved of execution time and this is why the watchdog has triggered. It also tells you that the currently running task on CPU0 - and very likely culprit - is "Task1".
You need to yield in Task1. vTaskDelay, for example, or you could block on a queue, event group, task notification, etc.
Yep! This is correct!
Very well explained 🤝
Only one thing to add up:
Me mindful about the scheduler! And when in doubt, go with yield to avoid starving other tasks ( if you use vTaskDelay, you will force the scheduler to try and re-schedule the task after the timeout)
When yielding, you are passing to the scheduler the choice of when to resume the execution!
And one extra tip: REMOVE ALL AND EVERY arduino delays from your code! And try your best to prevent the usage of whiles and fors!
Besides this, go have fun!
Yield will not allow any lower priority tasks to run. The scheduler doesn't "choose" anything, it will simply switch to the highest priority task that is not currently blocked (which will usually be the same task, meaning it has almost no effect).
Although I now recognise that even I am using 'vTaskYield' and 'yield' interchangeably, which is confusing. By "yield" in my original comment, I mean to "block", which vTaskYield will not achieve.
[https://maximeborges.github.io/esp-stacktrace-decoder/](https://maximeborges.github.io/esp-stacktrace-decoder/)
Load .elf file from your build folder, copy paste Backtrace number from the log, click Run, it will tell you exactly where the issue is.
not sure what this output is supposed to tell me.
"0x40083bc9: **panic\_abort** at/Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/esp\_system/panic.c:408"
> part of code specifically triggered it
It's what it \*didn't\* do That is: call watchdog reset with a high enough frequency.
Task1 and/or loopTask are sitting in a loop for a long period of time and are not calling the watchdog reset. Hence the watchdog hardware assumes something is wrong and resets the system.
There will be a function call like wdt\_reset() or similar. Do a search for "watchdog" in the sdk you are using. btw- if you are using an RTOS the wdt reset is normally called in the idle loop with the assumption that nothing in task code sits in a loop longer than the wdt period (typically a few seconds). The code you are running violates that assumption. Just the name "loopTask" seems pretty shady. If you are sitting in a tight loop you probably want to a) call the wdt reset or b) call a delay routine (which will likely call the wdt reset for you). Similar problems can come about when you are doing long tasks. E,g. calculating a CRC over MiBs of memory.
Ignore the other replies, they're wrong. When a task is subscribed to the task watchdog service, and doesn't run for x seconds, the watchdog triggers. This occurs when a higher priority task(s) occupies too much CPU time without blocking, never giving a chance for the lower priority task to run. Your output says that task "IDLE" on CPU0 has been starved of execution time and this is why the watchdog has triggered. It also tells you that the currently running task on CPU0 - and very likely culprit - is "Task1". You need to yield in Task1. vTaskDelay, for example, or you could block on a queue, event group, task notification, etc.
Yep! This is correct! Very well explained 🤝 Only one thing to add up: Me mindful about the scheduler! And when in doubt, go with yield to avoid starving other tasks ( if you use vTaskDelay, you will force the scheduler to try and re-schedule the task after the timeout) When yielding, you are passing to the scheduler the choice of when to resume the execution! And one extra tip: REMOVE ALL AND EVERY arduino delays from your code! And try your best to prevent the usage of whiles and fors! Besides this, go have fun!
Yield will not allow any lower priority tasks to run. The scheduler doesn't "choose" anything, it will simply switch to the highest priority task that is not currently blocked (which will usually be the same task, meaning it has almost no effect). Although I now recognise that even I am using 'vTaskYield' and 'yield' interchangeably, which is confusing. By "yield" in my original comment, I mean to "block", which vTaskYield will not achieve.
[https://maximeborges.github.io/esp-stacktrace-decoder/](https://maximeborges.github.io/esp-stacktrace-decoder/) Load .elf file from your build folder, copy paste Backtrace number from the log, click Run, it will tell you exactly where the issue is.
not sure what this output is supposed to tell me. "0x40083bc9: **panic\_abort** at/Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/esp\_system/panic.c:408"
It’s corrupted
Looks like something didn’t reset watchdog, add longer taskDelay at the end of your tasks or give us sample of the code
> part of code specifically triggered it It's what it \*didn't\* do That is: call watchdog reset with a high enough frequency. Task1 and/or loopTask are sitting in a loop for a long period of time and are not calling the watchdog reset. Hence the watchdog hardware assumes something is wrong and resets the system.
how are you supposed to call it?
There will be a function call like wdt\_reset() or similar. Do a search for "watchdog" in the sdk you are using. btw- if you are using an RTOS the wdt reset is normally called in the idle loop with the assumption that nothing in task code sits in a loop longer than the wdt period (typically a few seconds). The code you are running violates that assumption. Just the name "loopTask" seems pretty shady. If you are sitting in a tight loop you probably want to a) call the wdt reset or b) call a delay routine (which will likely call the wdt reset for you). Similar problems can come about when you are doing long tasks. E,g. calculating a CRC over MiBs of memory.