This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TI Bluetooth Stack with Shared Transport Driver Enabled

I am working on WL1873Q (the one with GPS IP) using BBB + TI Processor SDK V03.00.00.04 + AM335x BluetopiaLinux Production V4.0.3.0.1.0

Before adding ti-st driver (to make GPS work), my device tree has tibt node, Bluetopia works ok. In order to make ti-st driver work, tibt node was changed to kim node to accomodate GPS driver, but Bluetopia stops working. Please refer to terminal outputs at the end of this post.

Q1: How to make Bluetopia work with kim node in the device tree? or how to make bluetooth and GPS both work with shared transport driver?

Q2: In the old TI Wiki "TI Bluetooth Stack for WL18xx - Getting started guide" (saved to local pc on 12/14/2016), I read "currently all available serial SDK need the following patch to the serial driver for having flow control working which is needed for bluetooth". A table below this line listed the first patch as "Diable shared transport patch". 

Is SDK V03.00.00.04 the one that needs to have its shared transport disabled in the device tree if using bluetopia?

Q3: In the updated TI Wiki "TI Bluetooth Stack for WL18xx - Getting started guide (http://processors.wiki.ti.com/index.php/TI_Bluetooth_Stack_for_WL18xx_-_Getting_Started_Guide), 

The requirements on patches are gone. What are the difference between  TI Bluetooth 4.2 Stack Add-On for Linux and V4.0V4.0.3.0.1.03.01? Can the former one be used for my application?

root@am335x-evm:~/BluetopiaPM/bin# ./SS1BTPM &
[1] 800
root@am335x-evm:~/BluetopiaPM/bin# ./SS1Tool cmd 0x04 0x009
*** Error in `./SS1BTPM': free(): invalid pointer: 0x0022dbe4 ***
Error: Can't open /proc/device-tree/tibt/dev_nameError: Can't open /proc/device-tree/tibt/baud_rateError: Can't open /proc/device-tree/tibt/flow_cntrlError: Can't open /proc/device-tree/tibt/nshutdown_gpioServer has been Un-Registered.
DEVM>The Bluetooth device is disabled and an error occurred while attempting enable it (-10032).
^C
[1]+ Aborted (core dumped) ./SS1BTPM
root@am335x-evm:~/BluetopiaPM/bin#

root@am335x-evm:/proc# ls -al device-tree
lrwxrwxrwx 1 root root 29 Jul 8 22:47 device-tree -> /sys/firmware/devicetree/base


root@am335x-evm:/sys/firmware/devicetree/base/kim# ls -al
drwxr-xr-x 2 root root 0 Jul 8 22:46 .
drwxr-xr-x 15 root root 0 Jul 8 22:43 ..
-r--r--r-- 1 root root 4 Jul 8 22:47 baud_rate
-r--r--r-- 1 root root 4 Jul 8 22:47 compatible
-r--r--r-- 1 root root 11 Jul 8 22:47 dev_name
-r--r--r-- 1 root root 4 Jul 8 22:47 flow_cntrl
-r--r--r-- 1 root root 4 Jul 8 22:47 name
-r--r--r-- 1 root root 4 Jul 8 22:47 nshutdown_gpio


root@am335x-evm:/sys/devices/platform/kim# ls -al
drwxr-xr-x 3 root root 0 Jul 8 22:43 .
drwxr-xr-x 22 root root 0 Jul 8 22:43 ..
-r--r--r-- 1 root root 4096 Jul 8 23:18 baud_rate
-r--r--r-- 1 root root 4096 Jul 8 23:18 dev_name
lrwxrwxrwx 1 root root 0 Jul 8 23:18 driver -> ../../../bus/platform/drivers/kim
-rw-r--r-- 1 root root 4096 Jul 8 23:18 driver_override
-r--r--r-- 1 root root 4096 Jul 8 23:18 flow_cntrl
-r--r--r-- 1 root root 4096 Jul 8 23:17 install
-r--r--r-- 1 root root 4096 Jul 8 23:18 modalias
lrwxrwxrwx 1 root root 0 Jul 8 23:18 of_node -> ../../../firmware/devicetree/base/kim
drwxr-xr-x 2 root root 0 Jul 8 23:18 power
lrwxrwxrwx 1 root root 0 Jul 8 22:43 subsystem -> ../../../bus/platform
-rw-r--r-- 1 root root 4096 Jul 8 22:43 uevent

  • Hi Buli,

    The TI Dual-mode Bluetooth stack does not use the shared transport. All it needs it either tibt in device-tree or a dynamic configuration file like the one listed on the following page.

    processors.wiki.ti.com/.../TI_Bluetooth_Stack_for_WL18xx_-_Getting_Started_Guide

    The problem in your case is not related to the stack itself, but the shared transport driver. It is not allowing the tty port to be used from user space (for the TI Bluetooth stack). This is causing the errors. 

    We are investigating possible workarounds to this and we will follow up over emails regarding what changes you might want to make to shared transport driver to prevent this.

    Best regards,

    Vihang