Skip to main content
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 watchdogsTimeout duration (in seconds)OwnerWhen expiredResult
Nonsecure WD bark11HLOSIRQ to Qualcomm TEEHLOS falls to Panic
Nonsecure WD bite12HLOSFast interrupt request (FIQ) to Qualcomm TEEQualcomm TEE asserts PS_HOLD
Secure WD bark6Qualcomm TEEFIQ to Qualcomm TEEQualcomm TEE just pets secure WD
Secure WD bite22Qualcomm TEEAsserting PS_HOLDPower 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
    You can modify the configuration file with the following values: 
    RuntimeWatchdogSec=30
ShutdownWatchdogSec=10
For more information about the configuration file values, see the following: 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.

​
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.

​
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.