# Debug common system issues

Some common system issues are watchdog (WD) timeout, bus hang, timeout error, and hardware reset. The following sections provide information about how to identify and debug such system issues.

## Debug watchdog timeout issues

A WD is a fixed-length counter that allows a system to recover from an unexpected hardware or software catastrophe. Unless the system periodically pets the WD timer, it assumes a catastrophe and resets the subsystem or the entire system depending on the triggered WD.

The following are the different types of WD implementations:

> 
> 
> - Hardware WD
> - Software WD
> - Bark
> - Bite

The following table summarizes different types of WD implementations.

Table: Watchdog implementations

| Types of watchdogs | Timeout duration (in seconds) | Owner | When expired | Result |
| --- | --- | --- | --- | --- |
| Nonsecure WD bark | 11 | HLOS | IRQ to Qualcomm TEE | HLOS falls to `Panic` |
| Nonsecure WD bite | 12 | HLOS | Fast interrupt request (FIQ) to Qualcomm TEE | Qualcomm TEE asserts `PS_HOLD` |
| Secure WD bark | 6 | Qualcomm TEE | FIQ to Qualcomm TEE | Qualcomm TEE just pets secure WD |
| Secure WD bite | 22 | Qualcomm TEE | Asserting `PS_HOLD` | Power management IC (PMIC) resets the system |

The system uses both hardware and software watchdogs. For example, modem DSP (mDSP) implements both software and hardware watchdogs. The hardware WD module ensures that the processor is active and consists of a timer that counts down from a predetermined value. If the corresponding CPU core doesn't reset the timer, it eventually counts to 0 (zero) and triggers a WD timeout.

### WD for application processor CPU

**Nonsecure hardware watchdog**

- Every 10 seconds, the HLOS triggers a timer event to pet the nonsecure hardware WD. If the HLOS doesn't pet the nonsecure WD for 11 seconds, the nonsecure WD bark fires and the HLOS must handle it. If the HLOS can't handle it, the HLOS falls into panic.
- If the HLOS is unable to handle nonsecure WD bark, it triggers a nonsecure WD bite and sends it to Qualcomm TEE, causing the Qualcomm TEE to fall into a fatal error.
- In Qualcomm Linux, upstream WD driver is located at the `drivers/watchdog/qcom-wdt.c` path. The following is the WD configuration file:

/# mount -o remount,rw /usr/
        
        /# cat /usr/lib/systemd/system.conf.d/00-systemd-conf.conf
        Copy to clipboard

    You can modify the configuration file with the following values:

RuntimeWatchdogSec=30
        
        ShutdownWatchdogSec=10
        Copy to clipboard

For more information about the configuration file values, see the following:

- [System and session service manager configuration file](https://manpages.debian.org/jessie/systemd/systemd-system.conf.5.en.html)
- [Linux watchdog driver API](https://www.kernel.org/doc/html/latest/watchdog/watchdog-api.html)

**Secure hardware watchdog**

- Every 6 seconds, Qualcomm TEE triggers a secure WD bark as a fast interrupt request (FIQ). The FIQ handler in the Qualcomm TEE pets the secure hardware WD. This isn't an error or fatal issue.
- If Qualcomm TEE can't handle the secure WD bark for 22 seconds, the secure WD bite expires. Then, the PMIC asserts the `PS_HOLD` pin, and eventually, the entire system is reset.

The complete functionality of this feature is available to licensed developers with authorized access. For more information about debugging WD issues, see [Qualcomm Linux Debug Guide -
Addendum.](https://docs.qualcomm.com/bundle/resource/topics/80-80022-12A/general_system_debugging.html#watchdog_timeout)

## Debug bus hang and timeout issues

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
- Memory protection

Some failures or timeout on these components may cause system errors, which the system reports to the Qualcomm TEE.

This feature is available to licensed developers with authorized access. For more information about debugging bus hang and timeout errors, see
[Qualcomm Linux Debug Guide - Addendum](https://docs.qualcomm.com/bundle/resource/topics/80-80022-12A/general_system_debugging.html#erroneous_transaction_on_bus_error_and_timeout).

## Identify the cause of hardware reset

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 the hardware reset is crucial.

This feature is available to licensed developers with authorized access. For more information about debugging hardware reset issues, see [Qualcomm Linux Debug Guide -
Addendum](https://docs.qualcomm.com/bundle/resource/topics/80-80022-12A/general_system_debugging.html#reset_hardware).

Last Published: May 14, 2026

[Previous Topic
Debug using the crash utility tool](https://docs.qualcomm.com/bundle/publicresource/80-80022-12/topics/crash_utility.md) [Next Topic
Debug non-HLOS](https://docs.qualcomm.com/bundle/publicresource/80-80022-12/topics/debug-non-hlos-subsystems.md)