# Debug common system issues

Some common system issues are watchdog 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 watchdog (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 watchdog timer, it assumes a catastrophe and resets the subsystem or the entire system, depending on the triggered watchdog.

The following are the different types of watchdog implementations:

> 
> 
> - Hardware watchdog
> - Software watchdog
> - Bark
> - Bite

The following table summarizes different types of watchdog implementation.

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 | 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 watchdog 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 watchdog timeout.

### Watchdog for application processor CPU

**Nonsecure hardware watchdog**

- Every 10 seconds, the HLOS triggers a timer event to pet the nonsecure hardware watchdog. If the HLOS doesn't pet the nonsecure watchdog for 11 seconds, the nonsecure watchdog 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 watchdog bark, it triggers a nonsecure watchdog bite and sends it to Qualcomm TEE, causing the Qualcomm TEE to fall into a fatal error.
- You can customize the watchdog pet and bark time using the kernel configuration options. For example, the following configuration sets the bark time to 13 seconds and the pet time to 11 seconds:

CONFIG_QCOM_WATCHDOG_BARK_TIME=13000
        Copy to clipboard

CONFIG_QCOM_WATCHDOG_PET_TIME=11000
        Copy to clipboard

**Secure hardware watchdog**

- Every 6 seconds, Qualcomm TEE triggers a secure watchdog bark as a fast interrupt request (FIQ). The FIQ handler in the Qualcomm TEE pets the secure hardware Watchdog. This issue isn't an error or fatal issue.
- If Qualcomm TEE can't handle the secure watchdog bark for 22 seconds, the secure watchdog 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 watchdog issues, see [Qualcomm Linux Debug Guide -
Addendum.](https://docs.qualcomm.com/bundle/resource/topics/80-70020-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-70020-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-70020-12A/general_system_debugging.html#reset_hardware).

Last Published: Jul 06, 2025

[Previous Topic
Debug Linux kernel space issues](https://docs.qualcomm.com/bundle/publicresource/80-70020-12/topics/debugging_linux_kernel.md) [Next Topic
Debug non-HLOS](https://docs.qualcomm.com/bundle/publicresource/80-70020-12/topics/debug-non-hlos-subsystems.md)