[SOLVED] Configuring PAN1325 Bluetooth Module for serial communication with Putty on Windows 7

I'm new to embedded linux and bluetooth, so apologies in advance for any slips in terminology or obvious questions.

I am currently working on an ARM board with the PAN1325 Bluetooth module attached through UART0. The end goal is to respond to requests from a Windows application over Bluetooth for different types of information from the board. Currently, I am trying to test by establishing a serial connection between a Windows 7 PC and the board.

On Windows:
In Bluetooth settings, I've selected the following:

• Allow Bluetooth device to find this computer
• Allow Bluetooth devices to connect to this computer
• Alert me when a new Bluetooth device wants to connect
• And I've added a COM port for incoming Bluetooth serial communication (COM10)

I then open COM10 in putty at a baud rate of 9600.

On the board:
Relevant Drivers in Kernel:

• bluetooth
• l2cap
• rfcomm
• bnep
• hidp
• hci_uart
• hci_vhci

After the board boots, I run the following commands.

$ hciattach /dev/ttyS0 texas
Found a Texas Instruments' chip!
Firmware file : /lib/firmware/TIInit_6.2.31.bts
Loaded BTS script version 1
Device setup complete
$ 
$ hciconfig hci0 up
$ 
$ hciconfig hci0 -a
hci0:   Type: BR/EDR  Bus: UART
        BD Address: 64:9C:8E:F5:8E:A7  ACL MTU: 1021:4  SCO MTU: 180:4
        UP RUNNING 
        RX bytes:723 acl:0 sco:0 events:22 errors:0
        TX bytes:112 acl:0 sco:0 commands:22 errors:0
        Features: 0xff 0xff 0x2d 0xfe 0x9b 0xff 0x79 0x83
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
        Link policy: 
        Link mode: SLAVE ACCEPT 
        Name: ''
        Class: 0x001f00
        Service Classes: Unspecified
        Device Class: Invalid Device Class!
        HCI Version: 2.1 (0x4)  Revision: 0x0
        LMP Version: 2.1 (0x4)  Subversion: 0x191f
        Manufacturer: Texas Instruments Inc. (13)
$ 
$ hciconfig hci0 piscan
$
$ hciconfig hci0
hci0:   Type: BR/EDR  Bus: UART
        BD Address: 64:9C:8E:F5:8E:A7  ACL MTU: 1021:4  SCO MTU: 180:4
        UP RUNNING PSCAN ISCAN 
        RX bytes:1014 acl:0 sco:0 events:26 errors:0
        TX bytes:133 acl:0 sco:0 commands:26 errors:0
$ 
$ hciconfig hci0 name NAME
$
$ hciconfig hci0 class 010704
$

At this point, I can scan for bluetooth devices from the Windows PC and see a device by the given name and class.

$ hcitool scan
        AA:BB:CC:DD:EE:FF       WINDOWS-PC
$ 
$ sdptool search --bdaddr AA:BB:CC:DD:EE:FF SP
Searching for SP on AA:BB:CC:DD:EE:FF ...
Service Name: COM10
Service Description: COM10
Service RecHandle: 0x1001b
Service Class ID List:
  "Serial Port" (0x1101)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 10
Language Base Attr List:
  code_ISO639: 0x656e
  encoding:    0x6a
  base_offset: 0x100
Profile Descriptor List:
  "Serial Port" (0x1101)
    Version: 0x0100

So the board can detect the pc and recognize the the SP service on channel 10. It may be good to note that when I run the same test without putty running on COM10, the SP service is not reported by the Windows PC.

$ rfcomm connect /dev/rfcomm0 AA:BB:CC:DD:EE:FF 10

At this point, a bubble appears in the tray of the Windows PC saying: "A bluetooth device is trying to connect. Click to allow this." I click the window, and another window opens asking for the pairing code for the device. I've tried 0, 0000 and 1234, but all of these end in an error with no connection. I have tried this while both adding the device beforehand (where an option to not use a pairing code is present) and without the device being added beforehand. When I turn off "Alert me when a new Bluetooth device wants to connect" option on Windows, nothing happens on the PC end. The board's error message is always:

Can't connect RFCOMM socket: Operation now in progress

I have trouble finding how to set the pairing code from the board's end. I assume this could be a fix, but I believe it is more likely that my entire process is inefficient. There is probably a far more acceptable way of establishing two-way communication with a Windows PC from a Linux board, but Google searches for such a solution are entirely filled with Linux/Windows PC users attempting to interface with an already configured Bluetooth device.

Any help with concepts, codes, or finding links to reading material would be greatly appreciated. If I left out any important information, it is probably because I do not realize its importance and my inattention to it could very well be part of the problem.

Thanks in advance for any aid!

Hey all. I was able to find a solution.


First, the PAN1325 is a Bluetooth v2.1 device. The pairing mechanism I was attempting to use, now called "Legacy Pairing," in which a PIN code is entered by the user is for Bluetooth devices v2.0 and before. The new method, called "Secure Simple Pairing (SSP)," requires no interaction from the user. This can be enabled/disabled with:

$ hciconfig hci0 sspmode 1
$ hciconfig hci0 sspmode 0

Second, I did not have a Service Discovery Protocol (SDP) daemon running. I encountered a lot of confusion as to how to do this with my version of Bluez - Bluez 4.99. Bluez has undergone several major changes in its life, but much of the documentation for older versions still circulates freely and tends to bury the newly developing guides for newer versions of Bluez.

For the latest versions of Bluez, the bluetoothd command has replaced all other daemons, including the sdpd. bluetoothd can be run in the foreground with debug output enabled with:

$ bluetoothd -n -d

When I did this, I found that the daemon was getting an error when starting, saying "Unable to get on D-Bus." This was the result of not every config file being moved over. Since I compiled Bluez from the source and moved it to the board manually (rather than make installing to a filesystem and then flashing that filesystem), I neglected to copy bluetooth.conf from ./src/bluetooth.conf in the source directory to /etc/dbus-1/system.d/bluetooth.conf on the board.

After I did this, I could run bluetoothd, which would start the SDP server. I could add the necessary serial port profile with:

$ sdptool add SP

And then the rfcomm commands could create a serial connection with the Windows PC as I described in my first post.

Though I am far from an expert, I'd be glad to share more of what I learned to anyone encountering issues with something similar. I'll go ahead and mark the thread as [SOLVED] now.