Connecting a Bluetooth device via USB on beagleboard

[ms12]

Using Android 1.6 Donut

I have the device (Bluegiga WT11, based on CSR Bluecore I believe)
connected via usb hub to beagle board. I don't have a tty that I can
spare. I have started hcid, hciconfig shows hci0 up, and I can
communicate with the device to read feature, etc. So I believe it is
basically working at the console level.

But if I try to enable Bluetooth via the Android settings on the
touchscreen, it briefly blinks on then off. The logcat shows

D/BluetoothDeviceService( 907): Bluetooth state 0 -> 1
D/BluetoothDeviceService( 907): Bluetooth state 1 -> 0

which seems to mean it tries to turn on but goes right back off.

Is there a way to get this to work, or will it only work thru a tty
that is hciattach'd ?

Mike

[ms12]

I found out how to get rfkill enabled in kernel, but there are no
directories under it, just /sys/class/rfkill. Symptoms still the
same, bluetooth blinks on and off immediately when trying to enable
it. This thread

http://groups.google.com/group/android-porting/browse_thread/thread/c37f87e81f63e7cc/32ef5a457e2eeef7?lnk=gst&q=problem+when+trying+to+on+bluetooth+under+beagleboard#32ef5a457e2eeef7

suggests you need some drivers for the wl127x chip from TI, but this
is device is not a WL127x chip, it is an external eval board connected
via USB.

Is there a way to get this to work?

Thanks,
Mike

[Pavan Savoy]

Well you have to write one.

http://android.git.kernel.org/?p=kernel/omap.git;a=blob;f=drivers/misc/wl127x-rfkill.c;h=bc47ed43dc7cf8e66332d331266a756e8e711ebb;hb=refs/heads/android-omap-2.6.32

can be your reference.
With this sort of a driver you will get entries under /sys/class/rfkill/
also did you first try it out from a console, just to make sure your usb-BT device works?

because if that had worked you would have got atleast 1 entry under rfkill/ directory from hci core BT sub-system in kernel.

--
unsubscribe: android-porti...@googlegroups.com
website: http://groups.google.com/group/android-porting

--
--Pavan Savoy

[MikeS]

I think it is working from the console.
For example:
# hciconfig -a
hci0:   Type: USB
        BD Address: 00:07:80:93:84:47 ACL MTU: 310:10 SCO MTU: 64:8
        UP RUNNING PSCAN
        RX bytes:978 acl:0 sco:0 events:29 errors:0
        TX bytes:605 acl:0 sco:0 commands:29 errors:0
        Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x83
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy: RSWITCH HOLD SNIFF PARK
        Link mode: SLAVE ACCEPT
        Name: 'beagleboard'
        Class: 0x40020c
        Service Classes: Telephony
        Device Class: Phone, Smart phone
        HCI Ver: 2.1 (0x4) HCI Rev: 0x13e2 LMP Ver: 2.1 (0x4) LMP Subver: 0x13e2
        Manufacturer: Cambridge Silicon Radio (10)

And if I turn Bluetooth on in my phone and do an   hcitool scan    if finds the phone
# hcitool scan
Scanning ...
        00:23:AF:4D:xx:xx       Motorola Phone

Still nothing in /sys/class/rfkill  

Any suggestions on where to look? 

Thanks much for your help.
Mike

[Pavan Savoy]

wow.. this is confusing..
actually the HCI core or BT subsystem should have created an rfkill entry for you.

note that this has nothing to do with the rfkill entry which is required for bluedroid to turn on BT from the UI !!!

so on a generic system... where on android BT works from UI you should see...
2 rfkill entries. 1 named hci0 and another named after the manufacturer.. (or whatever you like.. since you write it...)

any case so which kernel version are you using? this rfkill mess came in on/after 2.6.32...
you can have a look @
net/bluetooth/ --> and grep for rfkill to look who creates rfkill entries.
also you will have to write your own rfkill driver, there is no escaping that !!

you might choose to ignore the values and all, but entry should exist for it to turn ON from UI. this you can look up on android FS code @ system/bluetooth/bluedroid/

--
--Pavan Savoy

[MikeS]

I'm running 2.6.29 ... maybe that is part of the issue? 
Also, is timing important?  I start the hcid manually after boot.  But shouldn't this create the rfkill/hci0 entry then?  And does the USB device have to be powered up and ready when hcid starts, or can it be connected later?

I'm not sure why an rfkill driver is necessary when the external board cannot be powered on or off by the processor anyway.  Does one just write something that returns "done" immediately when asked to power on or off?

Thanks.    Mike

[Pavan Savoy]

2.6.29?
Ok then forget what I mentioned about BT subsystem creating an rfkill.

So all you need is the 2.6.29's rfkill driver.
You can find it at drivers/misc/ of the kernel/omap project under 2.6.29 branch on git.source.android.com

well rfkill is VERY necessary for BT chips which need to be powered on by the apps processor.
in you usb case, it might be always ON.. but same is not the case with most UART BT chips.. which is more frequent on an embedded system.

So you can go ahead and remove off the rfkill toggling in bluedroid or write yourself a "fake" driver ...

(USB BT is more often used in the PC/laptop category)

--
--Pavan Savoy

[MikeS]

I'll look into fixing the rfkill toggling, but suppose I get that working.  Looking at bluedroid, it looks like it demands hciattach and a uart.  Will it work with a USB attached bluetooth module?

Mike

[Pavan Savoy]

Hnm, you can fake the service hciattach too..
like what we do is ...

service hciattach /system/bin/hciattach -l
    user root
# changing user to root from bluetooth is a potential security issue
# service hciattach_legacy is used instead of hciattach because, we dont
# have nodes named ttyHS0
    group bluetooth net_bt_admin misc
    disabled
    oneshot

so bluedroid thinks hciattach is running fine, but hciattach would just show help and quit..

--
--Pavan Savoy

[Ash]

Hey,

If you are working on source of android you can just remove all rfkill
related source from bluedroid/bluetooth.c build your source and it
should work!!


Like:

int bt_enable() {
LOGV(__FUNCTION__);

int ret = -1;
int hci_sock = -1;
int attempt;

/********************* Remove this **********************/
if (set_bluetooth_power(1) < 0) goto out;


..
..

..



Also check_bluetooth_power and set_bluetooth_power from other places

On Oct 8, 11:51 pm, Pavan Savoy <pavan.sa...@gmail.com> wrote:
> Hnm, you can fake the service hciattach too..
> like what we do is ...
>
> service hciattach /system/bin/hciattach -l
>     user root
> # changing user to root from bluetooth is a potential security issue
> # service hciattach_legacy is used instead of hciattach because, we dont
> # have nodes named ttyHS0
>     group bluetooth net_bt_admin misc
>     disabled
>     oneshot
>
> so bluedroid thinks hciattach is running fine, but hciattach would just show
> help and quit..
>
>
>
>
>
> On Fri, Oct 8, 2010 at 1:50 PM, MikeS <mstic...@gmail.com> wrote:
> > I'll look into fixing the rfkill toggling, but suppose I get that working.
> > Looking at bluedroid, it looks like it demands hciattach and a uart.  Will
> > it work with a USB attached bluetooth module?
>
> > Mike
>

[ms12]

Ok, I'm back trying to get this to work. To recap, trying to get an
external usb connected bluetooth device to work.
I've updated to android 2.1 Eclair.
One change I've noticed is that there is no longer and hcid service,
but there is a new bluetoothd service.
I've fixed the bluedroid so it doesn't open rfkill directories (there
are none, assumes power is always on) and does not start hciattach as
suggested above.

Manually doing an

hciconfig hci0 up

seems to enable communications with the device. I can get it to
discover my phone, for example, via hcitool scan at the console.

What I can't do is enable it from the Settings panel UI in Android.
Looks like maybe it blinks on for a ms or two, then goes right back
off.
I've put log entries in bluedroid/bluetooth.c set_bluetooth_power()
and it never goes there. The only thing I get in the log is

I/power ( 915): *** set_screen_state 1
I/power ( 915): *** set_screen_state 1
I/power ( 915): *** set_screen_state 1
V/BluetoothEventRedirector( 983): Received
android.bluetooth.adapter.action.STATE_CHANGED
V/BluetoothEventRedirector( 983): Received
android.bluetooth.adapter.action.STATE_CHANGED

I get the impression I'm missing a part of the enable process
somewhere. It doesn't even try and call the bluedroid stuff.

Any ideas on where to look?
Tbanks much in andvance
Mike

[Pavan Savoy]

I suppose the basic BOARD_HAVE_BLUETOOTH flag is already set?
and the JNI layer actually make calls to bluedroid !!!

Can you put in couple of debugs in the
/frameworks/base/core/jni/android_server_BluetoothService.cpp" ? just
to make sure you are in-fact building the right things?

--
--Pavan Savoy

[MikeS]

On Thu, Oct 21, 2010 at 2:20 PM, Pavan Savoy <pavan...@gmail.com> wrote:

I suppose the basic BOARD_HAVE_BLUETOOTH flag is already set?
and the JNI layer actually make calls to bluedroid !!!

Yep, BOARD_HAVE_BLUETOOTH is set.
 

Can you put in couple of debugs in the
/frameworks/base/core/jni/android_server_BluetoothService.cpp" ? just
to make sure you are in-fact building the right things?

Did this, and now it is calling bluedroid (not sure why it didn't before ...   )
Error I get is now
       E/bluedroid(  895): bt_enable: Timeout waiting for HCI device to come up

This means the ioctl call to the socket isn't succeeding. 
BUT, just above this is the following comment:
       // Try for 10 seconds, this can only succeed once hciattach has sent the
       // firmware and then turned on hci device via HCIUARTSETPROTO ioctl

So when I commented out hciattach, it looks like I also disabled some initializing of the device.
Will go try and hunt down HCIUARTSETPROTO in hciattach and what it is doing to "turn it on".
I'm assuming (hoping) that the socket is going directly to hci0, and I just have to set something
via the ioctl to turn it on.

Mike

[Pavan Savoy]

I thought you removed the whole hciattach starting from the bluedroid,
because you have USB device?
hciattach is for UART devices...

or you can have your init.c say hciattach -l for the hciattach service.
The important step I suppose here is ioctl HCIDEVUP.. so leave the
ioctl alone and try commenting hciattach, I guess that should work..

--
--Pavan Savoy

[MikeS]

It appears that my mistake was bringing up the interface manually at the console before trying to enable bluetooth via the UI.  It works if I don't do that. 

Paired it with my cell phone, and tried transferring a file, but the connection failed.  I don't know much about bluetooth, but I wonder if Android is set up for file transfer(a profile issue?), or maybe there is a permission problem somewhere.  I've had issues with those before.  Going to see if I can figure out where to look, pointers would be appreciated.

Thanks for your help in getting it going.
Mike