# Debug Source: [https://docs.qualcomm.com/doc/80-70017-13/topic/bt_debugging.html](https://docs.qualcomm.com/doc/80-70017-13/topic/bt_debugging.html) To debug Bluetooth issues, use host logs or over-the-air (OTA) logs. Host logs include Logcat and BTSnoop (stack)/HCI logs. These logs can be used for initial debugging. The following table lists the logs required to debug different Bluetooth issues. | Issue type | Logcat | BTSnoop/HCI | Kernel logs | OTA | PulseAudio | Subsystem restart (SSR) logs | | --- | --- | --- | --- | --- | --- | --- | | General | Required | Required | Not required | Recommended | Not required | Not required | | Bluetooth controller | Not required | Recommended | Not required | Required | Not required | Required | | Bluetooth on/off | Required | Not required | Not required | Not required | Not required | Required | | Crash | Required | Not required | Required | Not required | Not required | Required | | Audio | Not required | Required | Not required | Required | Required | Not required | ## Debug BlueZ stack Source: [https://docs.qualcomm.com/doc/80-70017-13/topic/bt_debugging.html](https://docs.qualcomm.com/doc/80-70017-13/topic/bt_debugging.html) Before you enable or collect logs, do the following: 1. Enable SSH to access your host device. For instructions, see [Log in using SSH](https://docs.qualcomm.com/bundle/publicresource/topics/80-70017-254/how_to.html#use-ssh). 2. Place the DUT and the remote device in the Bluetooth vicinity. 3. Run the SSH in command prompt using the following command: ssh root@Copy to clipboard **Example** If the IP address of the device is `10.92.160.222`, run the following command: ssh root@10.92.160.222Copy to clipboard 4. Connect to the SSH by entering the following password: oelinux123Copy to clipboard ### Enable BlueZ logs To enable BlueZ logs, do the following in SSH: 1. Enable read and write permissions by running the following command: mount -o remount rw /Copy to clipboard 2. Open the Bluetooth service file in a text editor. **Example** To open the bluetooth.service file in a VI editor, run the following command: vi /lib/systemd/system/bluetooth.serviceCopy to clipboard 3. Append `-d` option to the following line in the file: ExecStart=/usr/libexec/bluetooth/bluetoothd -dCopy to clipboard 4. Save the file. 5. Reload the Bluetooth daemon by running the following command: systemctl daemon-reloadCopy to clipboard 6. Restart Bluetooth by running the following command: systemctl restart bluetoothCopy to clipboard ### Collect BlueZ logs - To collect BlueZ user space logs, run the following command in SSH: journalctl -f -u bluetooth.service > /var/log/bluetooth.logCopy to clipboard - To collect all logs, run the following command in SSH: journalctl -f > /var/log/full.logCopy to clipboard ### Collect snoop logs To collect snoop logs, do the following in SSH: 1. Run the `hcidump` tool. 2. Save the file by running the following command: hcidump --save-dump=Copy to clipboard **Example** To save the snoop logs to snoop.log file, run the following command: hcidump --save-dump=/var/log/snoop.logCopy to clipboard ### Enable PulseAudio logs To enable PulseAudio logs, do the following in SSH: 1. Verify the status of PulseAudio by running the following command: systemctl status pulseaudioCopy to clipboard **Sample output** sh-5.1# systemctl status pulseaudio * pulseaudio.service - PulseAudio Sound Service Loaded: loaded (/lib/systemd/system/pulseaudio.service; enabled; vendor preset: enabled) Active: active (running) since Sun 1980-01-06 00:00:10 UTC; 27min ago Main PID: 1607 (pulseaudio) Tasks: 14 (limit: 6234) Memory: 19.8M CGroup: /system.slice/pulseaudio.service '- 1607 /usr/bin/pulseaudio -- system -- daemonize=no -v Jan 06 00:00:11 qcm6490 pulseaudio[1607]: session_close: 1376 exit, ret e Jan 06 00:00:11 qcm6490 pulseaudio[1607]: freeFrontEndIds: 7243: stream ty .. .110 Jan 06 00:80:11 qcm6490 pulseaudio[1607]: close: 514: Enter. deviceCount 1 ... ER) Jan 06 00:00:11 qcm6490 pulseaudio[1607]: Reset path: speaker-vbat Jan 06 00:00:11 qcm6490 pulseaudio[1607]: close: 528: Exit. deviceCount e ... s 0 Jan 06 00:00:11 qcm6490 pulseaudio[1607]: GetConcurrencyInfo: 5471: stream ... wed Jan 06 00:80:11 qcm6490 pulseaudio[1607]: GetConcurrencyInfo: 5471: stream ... wed Jan 06 00:00:11 qcm6490 pulseaudio[1607]: GetConcurrencyInfo: 5471: stream ... wed Jan 06 00:00:11 qcm6490 pulseaudio[1607]: deregisterStream: 3690: stream type 1 Jan 06 00:00:11 qcm6490 pulseaudio[1607]: pal_stream_close: 306: Exit. status 0 Hint: Some lines were ellipsized, use -l to show in full. sh-5.1#Copy to clipboard 2. Open the PulseAudio service file in a text editor. **Example** To open the pulseaudio.service file in a VI editor, run the following command: vi /lib/systemd/system/pulseaudio.serviceCopy to clipboard 3. Append `-vvvv` option to the following line in the file: /usr/bin/pulseaudio --system --daemonize=no -vvvvCopy to clipboard 4. Save the file. 5. Reload the Bluetooth daemon by running the following command: systemctl daemon-reloadCopy to clipboard 6. Restart PulseAudio by running the following command: systemctl restart pulseaudioCopy to clipboard ### Enable logs of ofono service To enable logs of ofono service, do the following in SSH: 1. Verify the status of the ofono service by running the following command: systemctl status ofonoCopy to clipboard **Sample output** sh-5.1# systemctl status ofono * ofono.service - Telephony service Loaded: loaded (/lib/systemd/system/ofono.service; enabled; vendor preset: enabled) Active: active (running) since Sun 1980-01-06 00:00:00 UTC; 30min ago Main PID: 990 (ofonod) Tasks: 1 (limit: 6234) Memory: 3.8M CGroup: /system.slice/ofono.service `- 990 /usr/sbin/ofonod -n Jan 06 00:00:00 qcm6490 systemd[1]: Started Telephony service. sh-5.1# |Copy to clipboard 2. Open the ofono service file in a text editor. **Example** To open the ofono.service file in a VI editor, run the following command: vi /lib/systemd/system/ofono.serviceCopy to clipboard 3. Append `-d` option to the following line in the file: ExecStart=/usr/sbin/ofonod -n -dCopy to clipboard 4. Save the file. 5. Reload the Bluetooth daemon by running the following command: systemctl daemon-reloadCopy to clipboard 6. Restart ofono service by running the following command: systemctl restart ofonoCopy to clipboard 7. Validate the status of the service to verify if it is running with the specified flags. ### Collect SSR dump logs In Qualcomm Linux software, if any Bluetooth subsystem module crashes, the SSR functionality collects the required firmware crash dumps in the Bluetooth driver. It then restarts the Bluetooth subsystem. The crash dump file is at the /var/spool/crash/ directory. Consider the following points about SSR logging: - To verify if SSR logs are enabled or disabled, run the following command: cat /sys/class/devcoredump/disabledCopy to clipboard Return: - `1`: SSR logging is disabled. - `0`: SSR logging is enabled. - To enable SSR logs, run the following command: echo 0 > /sys/class/devcoredump/disabledCopy to clipboard - To collect SSR logs manually, do the following: Note: To collect the SSR crash dump manually, ensure that the device Bluetooth is on. 1. Run the `hcitool` tool. 2. Send the crash command to the controller by running the following command: hcitool cmd 0x3f 0c 26Copy to clipboard **Sample output** hcitool cmd 0x3f 0c 26 < HCI Command: ogf 0x3f, ocf 0x000c, plen 1 26 > HCI Event: 0xff plen 246 01 09 A5 7A 01 02 84 BD 4C 00 00 00 00 7C 0C 01 10 0C 8B 00 00 00 02 00 61 0C 8B 00 00 0C FC 00 00 AC 08 02 00 B8 04 02 00 08 08 08 08 09 09 09 09 10 10 10 10 11 11 11 11 04 00 00 00 80 FF 06 00 CC DE 06 00 67 0C 01 10 4A 0F 01 10 00 00 00 00 02 00 00 00 A0 E8 DE 06 00 0C 8B 00 00 0C FC 00 00 AC 08 02 00 84 16 02 00 3F 42 01 10 04 00 00 00 06 00 00 00 0C 8B 00 00 0C FC 00 00 3F 00 00 00 BD AE 02 00 04 00 00 00 FF FF 00 00 0C 8B 00 00 0C FC 00 00 3F 00 00 00 B1 BB 0D 10 90 FD 01 00 90 2B 01 00 10 36 01 00 4C 09 02 00 90 FD 01 00 15 C6 0D 10 90 2B 01 00 49 E2 02 10 00 00 00 00 00 00 00 10 35 D5 A5 2D 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 Copy to clipboard The crash triggered generates a BIN file at the /var/spool/crash/ directory. **Sample output** ls -l /var/spool/crash/ total 904 -r--------. 1 root root 458888 Jan 1 00:53 hci0_1970-01-01_00-53-36.bin -r--------. 1 root root 458888 Jan 1 00:58 hci0_1970-01-01_00-58-18.bin Copy to clipboard 3. Ensure that the BIN file is generated at the /var/spool/crash/ directory. Note: - Only the advanced build version supports the SSR feature. - If you observe any timeout or Bluetooth hardware error, contact Qualcomm and share the BIN file. ## Debug Fluoride stack Source: [https://docs.qualcomm.com/doc/80-70017-13/topic/bt_debugging.html](https://docs.qualcomm.com/doc/80-70017-13/topic/bt_debugging.html) To debug Bluetooth issues in software with Fluoride stack, use host logs or OTA logs. ### Host logs **Prerequisites** Ensure that you enable SSH to access your host device. For instructions, see [Log in using SSH](https://docs.qualcomm.com/bundle/publicresource/topics/80-70017-254/how_to.html#use-ssh). **Procedure** To get the Bluetooth logs from the DUT, do the following: 1. Turn off Bluetooth on the device. 2. Run SSH in the command prompt using the following command: ssh root@Copy to clipboard **Example** If the IP address of the device is `10.92.160.222`, run the following command: ssh root@10.92.160.222Copy to clipboard 3. Connect to the SSH by entering the following password: oelinux123Copy to clipboard 4. Get the Logcat logs as follows: 1. Pull the Bluetooth stack configuration file, bt\_stack.conf, from the device by running the following command: scp -r root@:/etc/bluetooth/bt_stack.conf Copy to clipboard To pull a file to the current file path of the PC, enter the `` as `.` in the command. Note: When prompted for a password, enter `oelinux123` to authenticate a file transfer via the Secure Copy Protocol (SCP). **Example** The IP address of the device is `10.92.160.222`. To pull the `bt_stack.conf` file from the device, run the following command: scp -r root@10.92.160.222:/etc/bluetooth/bt_stack.conf .Copy to clipboard 2. Change the log level to verbose by configuring the following parameters in the Bluetooth stack configuration file, `bt_stack.conf`: TRC_HCI=6 TRC_L2CAP=6 TRC_RFCOMM=6 TRC_OBEX=6 TRC_AVCT=6 TRC_AVDT=6 TRC_AVRC=6 TRC_AVDT_SCB=6 TRC_AVDT_CCB=6 TRC_A2D=6 TRC_SDP=6 TRC_SMP=6 TRC_BTAPP=6 TRC_BTIF=6 TRC_BNEP=6 TRC_PAN=6 TRC_HID_HOST=6 TRC_HID_DEV=6Copy to clipboard 3. Push the Bluetooth stack configuration file to the device by running the following command: scp -r bt_stack.conf root@:/etc/bluetooth/bt_stack.confCopy to clipboard **Example** The IP address of the device is `10.92.160.222`. To push the `bt_stack.conf` file to the device, run the following command: scp -r bt_stack.conf root@10.92.160.222:/etc/bluetooth/bt_stack.confCopy to clipboard 4. Collect the Logcat logs by running the following command: journalctl -f > all_logs.txtCopy to clipboard 5. Pull the Logcat file by running the following command: scp -r root@: Copy to clipboard To pull a file to the current file path of the PC, enter the `` as `.` in the command. **Example** The IP address of the device is `10.92.160.222`. To pull the Logcat file all\_logs.txt to the current file path, run the following command: scp -r root@10.92.180.250:/home/root/all_logs.txt .Copy to clipboard 5. Pull the BTSnoop logs by running the following command: scp -r root@:/etc/bluetooth/btsnoop_hci.log Copy to clipboard The HCIDUMP/BTSnoop logs are useful to determine whether the issue relates to the application, Bluetooth host, Bluetooth chipset, or a remote device. To pull a file to the current file path of the PC, enter the `` as `.` in the command. **Example** The IP address of the device is `10.92.160.222`. To pull the `btsnoop_hci.log` file, run the following command: scp -r root@10.92.160.222:/etc/bluetooth/btsnoop_hci.log .Copy to clipboard If there is a composite USB, Q6 handles the waking host, connects the USB, and then sends the crash dump to the host. In the standalone mode, Bluetooth wakes up the host and sends the crash dump. ### OTA logs OTA logs are also known as sniffer logs. Bluetooth OTA logs are captured using the FTS/Ellisys sniffer tool to debug certain chipset or remote device issues, and environment issues. Last Published: Dec 26, 2024 [Previous Topic Perform Bluetooth HFP audio gateway functions](https://docs.qualcomm.com/bundle/publicresource/80-70017-13/topics/perform-bluetooth-hfp-ag-functions.md) [Next Topic References](https://docs.qualcomm.com/bundle/publicresource/80-70017-13/topics/references_acronyms.md)