wdts.rst 8.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166
  1. Watchdogs
  2. =========
  3. Overview
  4. --------
  5. The ESP-IDF has support for multiple types of watchdogs, with the two main ones being: The Interrupt Watchdog Timer
  6. and the Task Watchdog Timer (TWDT). The Interrupt Watchdog Timer and the TWDT
  7. can both be enabled using :ref:`project-configuration-menu`, however the TWDT can also be
  8. enabled during runtime. The Interrupt Watchdog is responsible for detecting
  9. instances where FreeRTOS task switching is blocked for a prolonged period of
  10. time. The TWDT is responsible for detecting instances of tasks running without
  11. yielding for a prolonged period.
  12. Interrupt watchdog
  13. ^^^^^^^^^^^^^^^^^^
  14. The interrupt watchdog makes sure the FreeRTOS task switching interrupt isn't blocked for a long time. This
  15. is bad because no other tasks, including potentially important ones like the WiFi task and the idle task,
  16. can't get any CPU runtime. A blocked task switching interrupt can happen because a program runs into an
  17. infinite loop with interrupts disabled or hangs in an interrupt.
  18. The default action of the interrupt watchdog is to invoke the panic handler. causing a register dump and an opportunity
  19. for the programmer to find out, using either OpenOCD or gdbstub, what bit of code is stuck with interrupts
  20. disabled. Depending on the configuration of the panic handler, it can also blindly reset the CPU, which may be
  21. preferred in a production environment.
  22. The interrupt watchdog is built around the hardware watchdog in timer group 1. If this watchdog for
  23. some reason cannot execute the NMI handler that invokes the panic handler (e.g. because IRAM is
  24. overwritten by garbage), it will hard-reset the SOC. If the panic handler executes, it will display
  25. the panic reason as "Interrupt wdt timeout on CPU0" or "Interrupt wdt timeout on CPU1" (as
  26. applicable).
  27. Configuration
  28. @@@@@@@@@@@@@
  29. The interrupt watchdog is enabled by default via the :ref:`CONFIG_ESP_INT_WDT` configuration
  30. flag. The timeout is configured by setting :ref:`CONFIG_ESP_INT_WDT_TIMEOUT_MS`. The default
  31. timeout is higher if PSRAM support is enabled, as a critical section or interrupt routine that
  32. accesses a large amount of PSRAM will take longer to complete in some circumstances. The INT WDT
  33. timeout should always be longer than the period between FreeRTOS ticks (see
  34. :ref:`CONFIG_FREERTOS_HZ`).
  35. Tuning
  36. @@@@@@
  37. If you find the Interrupt watchdog timeout is triggering because an interrupt or critical section is
  38. running longer than the timeout period, consider rewriting the code: critical sections should be
  39. made as short as possible, with non-critical computation happening outside the critical
  40. section. Interrupt handlers should also perform the minimum possible amount of computation, consider
  41. pushing data into a queue from the ISR and processing it in a task instead. Neither critical
  42. sections or interrupt handlers should ever block waiting for another event to occur.
  43. If changing the code to reduce the processing time is not possible or desirable, it's possible to
  44. increase the :ref:`CONFIG_ESP_INT_WDT_TIMEOUT_MS` setting instead.
  45. .. _task-watchdog-timer:
  46. Task Watchdog Timer
  47. ^^^^^^^^^^^^^^^^^^^
  48. The Task Watchdog Timer (TWDT) is responsible for detecting instances of tasks
  49. running for a prolonged period of time without yielding. This is a symptom of
  50. CPU starvation and is usually caused by a higher priority task looping without
  51. yielding to a lower-priority task thus starving the lower priority task from
  52. CPU time. This can be an indicator of poorly written code that spinloops on a
  53. peripheral, or a task that is stuck in an infinite loop.
  54. {IDF_TARGET_IDLE_TASKS:default="Idle task", esp32="Idle Tasks of each CPU"}
  55. By default the TWDT will watch the {IDF_TARGET_IDLE_TASKS}, however any task can
  56. subscribe to be watched by the TWDT. Each watched task must 'reset' the TWDT
  57. periodically to indicate that they have been allocated CPU time. If a task does
  58. not reset within the TWDT timeout period, a warning will be printed with
  59. information about which tasks failed to reset the TWDT in time and which
  60. tasks are currently running.
  61. It is also possible to redefine the function `esp_task_wdt_isr_user_handler`
  62. in the user code, in order to receive the timeout event and handle it differently.
  63. The TWDT is built around the Hardware Watchdog Timer in Timer Group 0. The TWDT
  64. can be initialized by calling :cpp:func:`esp_task_wdt_init` which will configure
  65. the hardware timer. A task can then subscribe to the TWDT using
  66. :cpp:func:`esp_task_wdt_add` in order to be watched. Each subscribed task must
  67. periodically call :cpp:func:`esp_task_wdt_reset` to reset the TWDT. Failure by
  68. any subscribed tasks to periodically call :cpp:func:`esp_task_wdt_reset`
  69. indicates that one or more tasks have been starved of CPU time or are stuck in a
  70. loop somewhere.
  71. A watched task can be unsubscribed from the TWDT using
  72. :cpp:func:`esp_task_wdt_delete()`. A task that has been unsubscribed should no
  73. longer call :cpp:func:`esp_task_wdt_reset`. Once all tasks have unsubscribed
  74. form the TWDT, the TWDT can be deinitialized by calling
  75. :cpp:func:`esp_task_wdt_deinit()`.
  76. The default timeout period for the TWDT is set using config item
  77. :ref:`CONFIG_ESP_TASK_WDT_TIMEOUT_S`. This should be set to at least as long as you expect any
  78. single task will need to monopolise the CPU (for example, if you expect the app will do a long
  79. intensive calculation and should not yield to other tasks). It is also possible to change this
  80. timeout at runtime by calling :cpp:func:`esp_task_wdt_init`.
  81. The following config options control TWDT configuration at startup. They are all enabled by default:
  82. {IDF_TARGET_IDLE_TASK:default="Idle task", esp32="CPU0 Idle task", esp32s3="CPU0 Idle task"}
  83. .. list::
  84. - :ref:`CONFIG_ESP_TASK_WDT` - the TWDT is initialized automatically during startup. If this option is disabled, it is still possible to initialize the Task WDT at runtime by calling :cpp:func:`esp_task_wdt_init`.
  85. - :ref:`CONFIG_ESP_TASK_WDT_CHECK_IDLE_TASK_CPU0` - {IDF_TARGET_IDLE_TASK} is subscribed to the TWDT during startup. If this option is disabled, it is still possible to subscribe the idle task by calling :cpp:func:`esp_task_wdt_add` at any time.
  86. :not CONFIG_FREERTOS_UNICORE: - :ref:`CONFIG_ESP_TASK_WDT_CHECK_IDLE_TASK_CPU1` - CPU1 Idle task is subscribed to the TWDT during startup.
  87. JTAG and watchdogs
  88. ^^^^^^^^^^^^^^^^^^
  89. While debugging using OpenOCD, the CPUs will be halted every time a breakpoint
  90. is reached. However if the watchdog timers continue to run when a breakpoint is
  91. encountered, they will eventually trigger a reset making it very difficult to
  92. debug code. Therefore OpenOCD will disable the hardware timers of both the
  93. interrupt and task watchdogs at every breakpoint. Moreover, OpenOCD will not
  94. reenable them upon leaving the breakpoint. This means that interrupt watchdog
  95. and task watchdog functionality will essentially be disabled. No warnings or
  96. panics from either watchdogs will be generated when the {IDF_TARGET_NAME} is connected to
  97. OpenOCD via JTAG.
  98. .. only:: SOC_XT_WDT_SUPPORTED
  99. XTAL32K Watchdog Timer (XTWDT)
  100. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  101. The XTAL32K watchdog makes sure the (optional) external 32 KHz crystal or oscillator is functioning correctly.
  102. When `XTAL32K_CLK` works as the clock source of `RTC_SLOW_CLK` and stops oscillating, the XTAL32K watchdog timer will detect this and generate an interrupt.
  103. It also provides functionality for automatically switching over to the internal, but less accurate oscillator as the `RTC_SLOW_CLK` source.
  104. Since the switch to the backup clock is done in hardware it can also happen during deep sleep. This means that even if `XTAL32K_CLK` stops functioning while the chip in deep sleep, waiting for a timer to expire, it will still be able to wake-up as planned.
  105. If the `XTAL32K_CLK` starts functioning normally again, you can call `esp_xt_wdt_restore_clk` to switch back to this clock source and re-enable the watchdog timer.
  106. Configuration
  107. @@@@@@@@@@@@@
  108. When the external 32KHz crystal or oscillator is selected (:ref:`CONFIG_{IDF_TARGET_CFG_PREFIX}_RTC_CLK_SRC`) the XTAL32K watchdog can be enabled via the :ref:`CONFIG_ESP_XT_WDT` configuration
  109. flag. The timeout is configured by setting :ref:`CONFIG_ESP_XT_WDT_TIMEOUT`. The automatic backup clock functionality is enabled via the ref:`CONFIG_ESP_XT_WDT_BACKUP_CLK_ENABLE` configuration.
  110. Interrupt Watchdog API Reference
  111. --------------------------------
  112. Header File
  113. ^^^^^^^^^^^
  114. * :component_file:`esp_system/include/esp_int_wdt.h`
  115. Functions
  116. ---------
  117. .. doxygenfunction:: esp_int_wdt_init
  118. Task Watchdog API Reference
  119. ----------------------------
  120. A full example using the Task Watchdog is available in esp-idf: :example:`system/task_watchdog`
  121. .. include-build-file:: inc/esp_task_wdt.inc