I’m reporting a Bluetooth (BLE) issue that has been affecting customers of ours who have Snapdragon 865 based devices including S20+ & S20 FE. This also affects devices of other manufacturers, who are also running SD 865 chip.
I reported the issue to google, via the android bug board, but they will not look into it because it doesn’t happen on pixel devices running stock android. (No pixel phones have SD865 SoC atm)
Issue 1: BLE stack crashes causing the ble stack to turn off and on again - our customers see this as ‘peripheral disconnections’ due to the forced reconnection when the ble turns on.
Issue 2: BLE corruption - packet data arrives into our app corrupted, ie not what the BLE peripheral sent. This causes our app to think our timestamp has rolled over causing the clock to jump ahead 49 days.
I can provide access to the supporting documents in the bug report for verification of my debugging.
We purchased a Samsung Galaxy S20 FE 5g specifically to debug this issue, and so far I have been able to reproduce the BLE stack crash (see last comment on the google bug report) but not the corruption yet. I will update here if/when this is reproduces, but i wanted to kick off with the crash as it seems that the corruption only happens after a crash.
I feel this is actually an issue Qualcomm might need to fix, but i can’t find any direct lines of support to them, so I’m going through the various device manufacturers.
Hi oliver,
I can not access the link https://issuetracker.google.com/issues/177246259
If you think the issue should be solved by Samsung then you can report the issue to Samsung developer support officially. Please below information with the report-
Issue reproduction step with demo video
btsnoop and dumpstate log(both from the pixel and Samsung device)
Expected result
Steps To Capture btSnoop & dumpsate Logs-
Press *#9900# on the dialer.
On USER Binary Go to Settings->About Device : Tap 7 times on Build Number to enable Developer Options
Go to Settings->Developer Options->Bluetooth HCI snoop log -> Enable this check box
Flight Mode > On / Off
Press *#9900# on the dialer -> Change Debug Level Disabled/LOW to MID -> Reboot device
REPRODUCE the issue scenario
Then capture the logs.
a) Press *#9900# on the dialer
b) Click on “RUN DUMPSTATE/LOGCAT”
c) It will start dumping the dumpstate.
d) Once it complete, Click on the “COPY TO SDCARD(INCLUDE CP RAMPDUMP”.
e) Dumpstate will be stored in the device storage.
Attach the device to PC
Get the logs from the device LOG folder and share it with us.(This LOG folder will contain both btsnoop & dumpstate log files)
Note : From the log folder in device, please ensure that files ‘dumpstate…’ and ‘btsnoop…’ files are present.
Hi thanks for the reply!
Yeah sorry, I don’t know why you can’t access the google bug report anymore - maybe because they marked as won’t fix.
Anyway, I have the requested documents available - the only caveat being i didn’t know about the debug level, but to me it looks like there’s enough information in there for samsung developers to look through.
I also captured BLE packets over the air which I can share, and the dumpstate contains btsnoop logs before and after the crash. The only problem is all the docs come way above the 4mb attachment limit of this forum - so please can you provide an email address or some way i can share the documents with samsung developers.
The Over the air wireshark capture is 300mb alone, and dumpsptate is 17mb…
In the mean time, here is a PDF of the google bug report which should provide the required background information: google-bugreport.pdf (2.3 MB)
01-20 18:07:18.171 6621 7191 V :::CARV:::CarvDeviceController$listenForData: (data) received: 1611166038.171, side: left - 03:90:cb:19:de:e0:e1:e5:e3:e5:e4:e3:f1:e3:e8:f2:f5:fc:fd:f6:ff:f6:f7:f5:f2:f2:f5:ea:f4:f7:f1:f6:f8:f6:fa:f8:f7:f6:f9:f7:f4:f1:e6:ef:f5:f8:f3:ef:e9:e6:f6:f7:70:02:06:0d:b1:80:df:00:60:00:e8:ff:4c:f7:2e:15:81:01:90
01-20 18:07:18.172 6621 7191 W Rust : deserializer/src/matcher.rs.deserializer::matcher:51 - 25236.78200000(time), 1611140803.75049996(zero), 1611166038.17100000(received_at))
01-20 18:07:18.173 6621 7191 V :::CARV:::CarvDeviceController$listenForData: (data) received: 1611166038.173, side: left - 03:90:cb:19:de:e0:e1:e5:e3:e5:e4:e3:f1:e3:e8:f2:f5:fc:fd:f6:ff:f6:f7:f5:f2:f2:f5:ea:f4:f7:f1:f6:f8:f6:fa:f8:f7:f6:f9:f7:f4:f1:e6:ef:f5:f8:f3:ef:e9:e6:f6:f7:70:02:06:0d:b1:80:df:00:60:00:e8:ff:4c:f7:2e:15:81:01:90
01-20 18:07:18.174 6621 7191 W Rust : deserializer/src/matcher.rs.deserializer::matcher:51 - 25236.78200000(time), 1611140803.75049996(zero), 1611166038.17300010(received_at))
01-20 18:07:18.177 846 3317 E vendor.qti.bluetooth@1.0-uart_controller: OnDataReady: Invalid hci packet type byte received 0x0, invalid_bytes_counter_ = 0
01-20 18:07:18.178 846 3317 E vendor.qti.bluetooth@1.0-uart_controller: OnDataReady: Invalid hci packet type byte received 0x0, invalid_bytes_counter_ = 1
01-20 18:07:18.178 846 3317 D vendor.qti.bluetooth@1.0-uart_controller: SsrCleanup: SSR triggered due to 18 skip sending special buffer
01-20 18:07:18.178 846 3317 D vendor.qti.bluetooth@1.0-uart_controller: ReportSocFailure: reason 18
01-20 18:07:18.190 846 3317 I vendor.qti.bluetooth@1.0-logger: Primary Reason for SoC Crash:Invalid HCI cmd type received
01-20 18:07:18.191 846 3317 I vendor.qti.bluetooth@1.0-logger: Secondary Reason for SoC Crash:Default at time :Wed Jan 20 18:07:18 2021
01-20 18:07:18.200 846 3317 D vendor.qti.bluetooth@1.0-uart_controller: ReportSocFailure send H/W error event to clients
01-20 18:07:18.200 846 3317 E vendor.qti.bluetooth@1.0-logger: Rx HW error event::Crash reason not found
01-20 18:07:18.201 2197 3322 E bt_hci : [BTCORE] Ctlr H/w error event - code:0xf
01-20 18:07:18.201 846 3317 I vendor.qti.bluetooth@1.0-logger: FrameCrashEvent: for crash reason :18-0-Wed Jan 20 18:07:18 2021
01-20 18:07:18.201 846 3317 D vendor.qti.bluetooth@1.0-uart_controller: SendCrashPacket send crash reasons to the client
01-20 18:07:18.201 2197 3322 E bt_btif : btif_dm_error_reporter_cback : 3
I’m still happy to share the full dumpstate, over the air ble packet capture and other resources if you provide an email or google account to share with.
Sorry i know asking for a google account on a samsung forum maybe a bit rude
Hello Oliver,
Thanks for the detail information. I think this issue should be analyzed by the experts from Samsung development team. As you have collected necessary information already, it will be better if you report it here, I think you will get better suggestion.
Thanks for the link - I didn’t know that support channel existed!
I have submitted a request with a link to this ticket - lets hope they can figure it out!
