Bluetooth crash and data corruption - Galaxy S20 FE and other SD 865 based devices

[oliver]

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)

Please see https://issuetracker.google.com/issues/177246259 for details of the issue(s)
TLDR;

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

[SNS_1205]

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-

1. Issue reproduction step with demo video
2. btsnoop and dumpstate log(both from the pixel and Samsung device)
3. Expected result

Steps To Capture btSnoop & dumpsate Logs-

1. Press *#9900# on the dialer.
2. On USER Binary Go to Settings->About Device : Tap 7 times on Build Number to enable Developer Options
3. Go to Settings->Developer Options->Bluetooth HCI snoop log -> Enable this check box
4. Flight Mode > On / Off
5. Press *#9900# on the dialer -> Change Debug Level Disabled/LOW to MID -> Reboot device
6. REPRODUCE the issue scenario
7. 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.
8. Attach the device to PC
9. 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.

Thanks.

[oliver]

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)

[oliver]

Also I’ll attach the bt_snoop capture from the dumpstate bugreport here:
btsnoop_hci.zip (1.5 MB)

And here’s the logcat capture from the time of the crash
samsung_s20_fe.logcat_reduced.txt (1.1 MB)

And here’s the interesting bits:

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

[SNS_1205]

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.

[oliver]

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!

As a side note, i’ve reported the same issue to OnePlus via their public forum
https://forums.oneplus.com/threads/bluetooth-crash-and-data-corruption-snapdragon-865-based-devices.1385886/

Just in case any of the info there is useful for debugging