Task Watchdog Triggered in ESP32 Application Using u8g2 Library

[williankleber]

Hello,

I am writing a program that, among many things, keeps an LCD screen constantly updated. I have a clock on the screen that displays hours, minutes, and seconds. Thus, I end up calling my screen update function at intervals of no more than 1000ms to show the new time. To update the screen, I am using the u8g2 library: github.com/olikraus/u8g2.

However, after developing a significant part of my application, I noticed that when I don't call the routine to update the screen, the task watchdog gets triggered a little over 5000ms, but it doesn't reset my CPU.

I don't recall activating the Task Watchdog Timer (WDT) at any point in my application, so I'm wondering if the u8g2 library might be using some WDT unbeknownst to me.

My question is: how can I prevent this triggering?

Here is the log:

Code: [Select all] [Expand/Collapse]

1. E (342118) task_wdt: Task watchdog got triggered. The following tasks/users did not reset the watchdog in time:
2. E (342118) task_wdt:  - IDLE (CPU 0)
3. E (342118) task_wdt: Tasks currently running:
4. E (342118) task_wdt: CPU 0: main
5. E (342118) task_wdt: CPU 1: IDLE
6. E (342118) task_wdt: Print CPU 0 (current core) backtrace
7.  
8.  
9. Backtrace: 0x400DE163:0x3FFB0E90 0x400DE2EA:0x3FFB0EB0 0x40082C21:0x3FFB0ED0 0x4008A3B3:0x3FFB5400 0x400DE4F6:0x3FFB5420 0x400D5F89:0x3FFB5460 0x400F4C68:0x3FFB54B0 0x4008A0CD:0x3FFB54E0
10. 0x400de163: task_wdt_timeout_handling at /home/wka/esp/esp-idf/components/esp_system/task_wdt/task_wdt.c:461 (discriminator 3)
11.  
12. 0x400de2ea: task_wdt_isr at /home/wka/esp/esp-idf/components/esp_system/task_wdt/task_wdt.c:585
13.  
14. 0x40082c21: _xt_lowint1 at /home/wka/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/xtensa_vectors.S:1226
15.  
16. 0x4008a3b3: vPortClearInterruptMaskFromISR at /home/wka/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/include/freertos/portmacro.h:568
17.  (inlined by) vPortExitCritical at /home/wka/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:532
18.  
19. 0x400de4f6: esp_task_wdt_reset at /home/wka/esp/esp-idf/components/esp_system/task_wdt/task_wdt.c:791
20.  
21. 0x400d5f89: app_main at /home/wka/WKA-Eletronics/AIC/AIC-P2/main/main.c:79 (discriminator 15)
22.  
23. 0x400f4c68: main_task at /home/wka/esp/esp-idf/components/freertos/app_startup.c:208 (discriminator 13)
24.  
25. 0x4008a0cd: vPortTaskWrapper at /home/wka/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:162

GeSHi © Codebox Plus Extension

Any help would be appreciated. Thank you!

[MicroController]

I don't recall activating the Task Watchdog Timer (WDT) at any point in my application, so I'm wondering if the u8g2 library might be using some WDT unbeknownst to me.

My question is: how can I prevent this triggering?

Here is the log:

Code: [Select all] [Expand/Collapse]

1. E (342118) task_wdt: Task watchdog got triggered. The following tasks/users did not reset the watchdog in time:
2. E (342118) task_wdt:  - IDLE (CPU 0)
3. E (342118) task_wdt: Tasks currently running:
4. E (342118) task_wdt: CPU 0: main
5. E (342118) task_wdt: CPU 1: IDLE
6. ...

GeSHi © Codebox Plus Extension

FreeRTOS's IDLE tasks (one per core) by default use the task watchdog. This is, among other things, because FreeRTOS needs the IDLE task to run some 'cleanup' tasks now and then.
In your case, the IDLE task on CPU 0 'failed' to reset the watchdog. This indicates that the code running on that core does not block, thereby not giving the low-priority IDLE task a chance to run. IOW, the application's task apparently uses 100% of the CPU for an extended period of time, which often results from some form of polling or busy-waiting implemented by that task, which should generally be avoided.
There may also be a bug which causes some loop to not exit but to keep spinning indefinitely; same effect as a busy-waiting loop.

How to prevent the issue?
Make sure your task(s) use appropriate blocking FreeRTOS function calls to allow lower-priority tasks to execute.

[williankleber]

Hello @MicroController, thank you for your response.

Indeed, the issue only occurs when I'm stuck in a loop waiting for some interaction. At a certain point, my code gets stuck in a loop that just tests my keyboard looking for any interaction. But when I call more complex functions, like serial communication and more intensive data manipulation, I believe there are commands and waits in those routines that allow the IDLE task to execute.

Could you suggest solutions to resolve my issue?
For example:

Code: Select all

while (true){
   if (swtc01){
      // key commands
   }
}

What's the correct way to implement this kind of test? Does FreeRTOS not allow the use of an infinite loop in my main.c?

[williankleber]

Hey everyone,

I've spent the last few days diving into FreeRTOS tasks and, wow, I'm blown away by the possibilities. I'm a veteran of direct MCU programming, typically working with "bare metal" programs. Recently, I needed to shift to a more powerful processor. I was trying to squeeze my system into the main loop, just like I used to do with Microchip PIC programs in 8 or 16-bit MCUs.

I managed to solve the issue I described by ditching my main loop and breaking my entire system into various tasks with different priorities. The result? Everything is running way smoother...

Now, I'm kicking myself: why didn't I jump on the FreeRTOS bandwagon earlier? I've always heard about this OS, even for Microchip's 16-bit MCUs, but never really got around to exploring it. If only I had been more open to it earlier, a lot of things would have been much easier...

Big thanks to everyone here. My system is now set to fly high, faster, and more efficiently.