Does the BLE stack have a log that can be retrieved or any way to do HI sniffing?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
ScKi_1600301
Level 2
Level 2

Our Android app is generating error 19, "Remote device has forced a disconnect." quite a few times when trying to make the initial connection.  Our Android developer has requested to know what the BLE stack is logging and the ability to sniff the HI (not sure what he means here).  Everything I've read so far on the Internet about error 19 occurs on other chip as well (TI, SiliconLabs, Nordic) and none of those manufacturers have ever indicated that the problem is in the chip but a problem with Android.  Does anybody here have any information?

0 Likes
1 Solution
Anonymous
Not applicable

The BLE APIs have functions to check the HI (Hardware Interface) states for behavior. There is not built-in logging functionality, but you can see all of the events that occur when handling the BLE Callback arguments/events. Then, you can just mirror those events/results to a UART output or something similar for logging.

CyBle_ProcessEvents() will handle all events that occured by calling the callback function passed to the CyBle_Start(callback); function.

If you have the data/events logged from the callback handler, then you should see more information on the issue(s).

One thing to note is that Android and other "standard" OS on devices tend to have quirks/rigid behavior involving certain hardware connections (such as bluetooth, usb, etc.) leading to issues that pertain only to specific hardware for specific OS and possibly even for specific versions.

My guess would be that you are missing handling some of the events to send responses to the android app that it is expecting in order to correctly connect.

View solution in original post

0 Likes
3 Replies
Anonymous
Not applicable

The BLE APIs have functions to check the HI (Hardware Interface) states for behavior. There is not built-in logging functionality, but you can see all of the events that occur when handling the BLE Callback arguments/events. Then, you can just mirror those events/results to a UART output or something similar for logging.

CyBle_ProcessEvents() will handle all events that occured by calling the callback function passed to the CyBle_Start(callback); function.

If you have the data/events logged from the callback handler, then you should see more information on the issue(s).

One thing to note is that Android and other "standard" OS on devices tend to have quirks/rigid behavior involving certain hardware connections (such as bluetooth, usb, etc.) leading to issues that pertain only to specific hardware for specific OS and possibly even for specific versions.

My guess would be that you are missing handling some of the events to send responses to the android app that it is expecting in order to correctly connect.

0 Likes

Thank you very much!  This is what I expected from reading the datasheet.

0 Likes
Anonymous
Not applicable

The HCI events in the callback have the lowest-level information, but I have not dug into them deeply enough to know how useful they are. But, if you are looking for more detailed information than what the standard BLE events in the callback provide, then the HCI events would be the next place to look for logging data.

Best of luck,

Elijah Pratt

0 Likes