# Debug common system issues Source: [https://docs.qualcomm.com/doc/80-70014-12/topic/general_system_debugging.html](https://docs.qualcomm.com/doc/80-70014-12/topic/general_system_debugging.html) Watchdog timeout, Bus hang, timeout error, and hardware reset are some common system issues. This information describes how to identify and debug such system issues. ## Watchdog issues Source: [https://docs.qualcomm.com/doc/80-70014-12/topic/general_system_debugging.html](https://docs.qualcomm.com/doc/80-70014-12/topic/general_system_debugging.html) A watchdog (WD) is a fixed-length counter that enables a system to recover from an unexpected hardware or software catastrophe. Unless the system periodically pets the watchdog timer, the watchdog timer assumes a catastrophe and resets the subsystem or the entire system depending on which watchdog is fired. There are multiple kinds of watchdog implementations – hardware watchdog and software watchdog, bark, bite, and so on. The following table summarizes the various types of watchdogs: | Types of watchdog | Timeout duration (in seconds) | Owner | When expired | Result | | --- | --- | --- | --- | --- | | Nonsecure WD bark | 11 | HLOS | IRQ to TrustZone | HLOS falls to Panic | | Nonsecure WD bite | 12 | HLOS | Fast interrupt request (FIQ) to TrustZone | TrustZone asserts PS\_HOLD | | Secure WD bark | 6 | TrustZone | FIQ to TrustZone | TrustZone just pets secure WD | | Secure WD bite | 22 | TrustZone | Asserting PS\_HOLD | PMIC resets the system | Both software and hardware watchdogs are used in the system. For example, mDSP implements both software and hardware watchdogs. The hardware watchdog module is used to ensure that the processor is active and consists of a timer that counts down from a predetermined value. If the timer is not reset by the corresponding CPU core, it eventually counts to 0 (zero) and triggers a watchdog timeout. ### Watchdog for application processor CPU **Nonsecure hardware watchdog** - Every 10 seconds, a timer event is triggered on HLOS to pet the nonsecure hardware watchdog. If the HLOS does not pet the nonsecure watchdog for 11 seconds, the nonsecure Watchdog bark fires and HLOS must handle it. If HLOS cannot handle it, HLOS falls into panic. - If the HLOS is unable to handle nonsecure watchdog bark, a nonsecure watchdog bite is triggered and sent to TrustZone. Then, TrustZone falls into a fatal error. - You can customize the watchdog pet and bark time using the kernel configuration. For example, the following configuration sets the bark time to 13 seconds and pet time to 11 seconds. CONFIG_QCOM_WATCHDOG_BARK_TIME=13000Copy to clipboard CONFIG_QCOM_WATCHDOG_PET_TIME=11000Copy to clipboard **Secure hardware watchdog** - Every 6 seconds, a secure watchdog bark is triggered to TrustZone as fast interrupt request (FIQ). The FIQ handler in the TrustZone pets the secure hardware Watchdog. This is not an error or fatal issue. - If TrustZone is unable to handle the secure watchdog bark for 22 seconds, the secure watchdog bite expires. Then, the PS\_HOLD pin is asserted on the PMIC and eventually the entire system is reset. The complete functionality of this feature is currently available for users who have full access to the proprietary software shipped with Qualcomm Linux. For more information on debugging watchdog issues, see [Qualcomm Linux Debug Guide - Addendum.](https://docs.qualcomm.com/bundle/resource/topics/80-70014-12A/general_system_debugging.html#watchdog_timeout) ## Bus hang and timeout error Source: [https://docs.qualcomm.com/doc/80-70014-12/topic/general_system_debugging.html](https://docs.qualcomm.com/doc/80-70014-12/topic/general_system_debugging.html) The SNoC, CNoC, xPU, TBU, and AHB are the system infrastructure components on the device, which are responsible for operations such as bus transaction, address translation, and memory protection. Some failures or timeout on these components result in a system error and are reported to the TrustZone. This feature is currently available for users who have full access to the proprietary software shipped with Qualcomm Linux. For more information on debugging bus hang and timeout errors, see [Qualcomm Linux Debug Guide - Addendum](https://docs.qualcomm.com/bundle/resource/topics/80-70014-12A/general_system_debugging.html#erroneous_transaction_on_bus_error_and_timeout). ## Hardware reset Source: [https://docs.qualcomm.com/doc/80-70014-12/topic/general_system_debugging.html](https://docs.qualcomm.com/doc/80-70014-12/topic/general_system_debugging.html) A secure watchdog, temperature sensor (TSENS), or PMIC issues can cause a hardware reset. The debugging approach for hardware reset issues depends on the cause of the hardware reset. Therefore, identifying the cause of hardware reset is crucial. This feature is currently available for users who have full access to the proprietary software shipped with Qualcomm Linux. For more information on debugging hardware reset issues, see [Qualcomm Linux Debug Guide - Addendum](https://docs.qualcomm.com/bundle/resource/topics/80-70014-12A/general_system_debugging.html#reset_hardware). Last Published: Jul 12, 2024 [Previous Topic Debug Linux kernel space](https://docs.qualcomm.com/bundle/publicresource/80-70014-12/topics/debugging_linux_kernel.md) [Next Topic Debug non-HLOS](https://docs.qualcomm.com/bundle/publicresource/80-70014-12/topics/debug-non-hlos-subsystems.md)