Starting Bluetooth on the Target

The Bluetooth services on the QNX CAR platform depend on several system services that must be started in a certain sequence as outlined below.

Starting the required services

Note: The following commands assume a Texas Instruments OMAP5432 EVM board.
  1. Make sure the following general system services are running. Note that Bluetooth as well as many applications throughout the system rely on these services:
    • pps
    • qdb
    • io-acoustic (for HFP)
    • mm-player (for AVRCP)

    For more information on starting these services and their dependencies, see the /etc/slm-config-all.xml file on your target.

    Note: To find out if a particular process is already running on your target, you can use the pidin utility (which displays information for all process IDs) and pipe the output through grep, specifying the process you're interested in. For example, to see if io-acoustic is running, use this command:

    # pidin | grep io-acoustic

  2. Make sure the devc-seromap_hci driver (for HCI shared transport) is running. Here's the command line:

    devc-seromap_hci -E -f -a -g 0x4805b000,142 -c48000000/16 0x48066000^2,137

  3. Start the io-bluetooth service. Note that this command specifies the BTS file for the OMAP5432 board:

    io-bluetooth -vvvvv -s /etc/system/config/bluetooth/WL18xx_2.x_SP2.8.bts

  4. Start the pps-bluetooth service:

    pps-bluetooth –vvvv

  5. Start the following services, if you need them:

    bluetooth-map-initiator –vv (for syncing messages)

    bluetooth-pbap-initiator –vv (for syncing the phonebook)

    ifwatchd -A /scripts/ -D /scripts/ pan0 (PAN scripts)

Note: If the io-bluetooth service isn't starting up, check the system log for multiple instances of HCC_RESET failure. If you find such errors, you'll need to slay and then restart the devc-seromap_hci driver. If you don't see those HCC-related errors, then make sure that the pps-bluetooth service is running, since it's the service that initializes io-bluetooth.

Command-line options for devc-seromap_hci

Although many general options are available for the devc-seromap_hci driver (because it's one of several drivers that rely on the io-char library), not all options make sense in the context of HCI. You must use the options as shown in Step 2 above to enable these specific features, but not their counterparts:
  • raw input mode (-E)
  • hardware flow control (-f)
  • auto-RTS (-a)

For instance, don't use edited mode—this would break HCI packet handling!

Here are the command-line options you can use when starting the devc-seromap_hci driver:

devc-seromap_hci [options] [port[^shift][,irq][,k]] &

Use auto-RTS when hardware flow control is enabled.
-b number
Define initial baud rate (default is 115200).
Note: Always start the driver with the default baud rate (115200). The BT chip will default to this rate when it comes out of reset, so the UART must be configured for this rate to issue the initial commands. If you want to increase the baud rate, the commands should be sent by the BT stack after the driver has reported CARRIER. The sequence is as follows:
  1. The BT stack writes the HCI commands for a change in baud rate to the BT chip via the HCI driver.
  2. The stack waits for the acknowledgment.
  3. The stack then changes the local HCI driver baud rate via the tcsetattr() call.
This sequence can be included in the *.bts file so that the value of the new baud rate won't need to be hard-coded into the BT stack.
-c clk[/div]
Set input clock rate (in hertz) and divisor.
-C number
Set size of canonical input buffer (default is 256 bytes).
Set options to edited mode.
Set options to raw mode (default).
Enable hardware flow control (default).
Disable hardware flow control.
-g gpio_base,gpio_pin
GPIO base and GPIO pin used for Bluetooth Enable. On driver initialization or UART transmit/receive error, the driver will toggle the GPIO connected to the chip's BT_EN or BT_RST pin and then issue the HCC_RESET command.
-I number
Set size of raw input buffer (default is 2048 bytes).
-l (0|1)
("el") Enable loopback mode (1=on, 0=off).
Name of Bluetooth Script. If you use the -n option, the driver will follow up the HCC_RESET command by uploading the provided file (*.bts). Note that the -n is optional since the Bluetooth stack sitting above the HCI UART driver can open the file directly and write the encoded HCI commands down to the driver via regular write() calls.

The driver will use the CD (Carrier Detect) line status to communicate when the interfaces are "ready" to be used, i.e., the driver will report CARRIER to the client, then the HCC_RESET and script load will be successfully completed. If the -n option isn't used to enable script load, then CARRIER is reported after the HCC_RESET. Note that the carrier signal is reported as dropped/lost when we reset the chip by toggling the GPIO pin.

-O number
Set size of output buffer (default is 2048 bytes).
Enable software flow control.
Disable software flow control (default).
-t number
Set receive FIFO trigger level (default is 16).
-T number
Set transmit FIFO trigger level (default is 8).
-u unit
Set serial unit number (default is 1).
-U uid:gid
Set the user ID and group ID.
Be verbose. Use multiple v's to increase verbosity (see sloginfo data).
Hex I/O address of serial port.
The spacing of the device registers as a power of 2 (e.g., 0 means registers are 1 byte apart, 1 means registers are 2 bytes apart, etc.). The default shift is 0.
Interrupt used by the port. To specify in hex, prefix with 0x.
Place this after the irq value to indicate that a Maxim RS-232 transceiver is used on this port, which requires sending it a null character to wake it up after going into Autoshutdown Plus mode.
Note: By default, the CREAD terminal flag will be disabled for all HCI interfaces (serbtX, sergpsX, and serfmX). The Bluetooth stack (or whatever app wants to use these interfaces) must set the CREAD flag to enable receive functionality (on a per-interface basis). For proper functionality, the client app must clear the flag when finished with the device/interface. This is because all interfaces share the same UART hardware—we don't want to get stuck in a flow-controlled state because there's no client reading from one of the interfaces. Flow control will be asserted when any of the device buffers reaches the defined high-water mark and won't be cleared until there's room in all interface buffers to receive more data. In other words, if the system doesn't care about GPS and there's no client reading from the sergpsX interface, we don't want the driver to buffer GPS data, which would eventually fill the buffer and assert the flow-controlled state.

Command-line options for io-bluetooth

Here are the command-line options you can use when starting the io-bluetooth service:

io-bluetooth [-d path][-f FD][-r file][-s path][-v]
-d path
Set the path to the serial driver (default is /dev/serbt1).
-f FD
Specify the file descriptor for the log destination (e.g., 2 for stderr).
-r file
Dump raw data to the specified text file. The relevant profile will be added to your filename after an underscore (i.e., file_profile.txt). For example, if you use -r /mydata, the result will create /mydata_map.txt and /mydata_pbap.txt.
-s path
Set the path to the BTS file (default is /etc/system/config/bluetooth/WL127x_2.0_SP1.bts). This file informs the hardware of the low-level parameters of the Bluetooth exchange, including the line numbers to use and the baud rate.
Be verbose. Use multiple v's to increase verbosity (see sloginfo data).

Command-line options for pps-bluetooth

Here are the command-line options you can use when starting the pps-bluetooth service:

pps-bluetooth [-f FD][-n name] [-U euid:egid][-v]
-f FD
Specify the file descriptor for the log destination (e.g., 2 for stderr).
-n name
Set the local name of the Bluetooth device.
-U euid:egid
Specify the effective user ID and group ID of the pps-bluetooth process.
Be verbose. Use multiple v's to increase verbosity (see sloginfo data).

Command line for bluetooth-map-initiator

The bluetooth-map-initiator executable (for syncing messages) takes only one option:

bluetooth-map-initiator [-v]
Be verbose. Use multiple v's to increase verbosity (see sloginfo data).

Command line for bluetooth-pbap-initiator

The bluetooth-pbap-initiator executable (for syncing the phonebook) takes only one option:

bluetooth-pbap-initiator [-v]
Be verbose. Use multiple v's to increase verbosity (see sloginfo data).

Automated startup via SLM

The System Launch and Monitor (SLM) is a utility used for automating the startup sequence of processes and any interprocess dependencies. SLM itself is started early in the boot sequence (from to launch complex applications consisting of many processes that must be started in a specific order. For more information, see the entry for slm in the OS Utilities Reference.

Here are the relevant sections from the /etc/slm-config-platform.xml configuration file for starting variant-specific processes (in this case for an OMAP5432 board):

HCI shared transport serial driver:
<SLM:component name="hci">
 <SLM:args>-E -f -a -g 0x4805b000,142 -c48000000/16 0x48066000^2,137</SLM:args>
 <SLM:waitfor wait="pathname">/dev/serbt1</SLM:waitfor>
 <SLM:stop stop="signal">SIGTERM</SLM:stop>
The io-bluetooth service:
<SLM:component name="bluetooth">
 <SLM:args>-vvvvv -s /etc/system/config/bluetooth/WL18xx_2.x_SP2.8.bts</SLM:args>
 <SLM:waitfor wait="pathname">/dev/io-bluetooth/btmgr</SLM:waitfor>
 <SLM:stop stop="signal">SIGTERM</SLM:stop>
The pps-bluetooth service:
<SLM:component name="pps-bluetooth">
 <SLM:stop stop="signal">SIGTERM</SLM:stop>
Phonebook sync automator:
<SLM:component name="pps-pbap-initiator">
 <SLM:stop stop="signal">SIGTERM</SLM:stop>
Messages sync automator:
<SLM:component name="pps-map-initiator">
 <SLM:stop stop="signal">SIGTERM</SLM:stop>
PAN scripts to start and stop dhcp.client to get an IP from the phone:
<SLM:component name="pan-if-monitor">
 <SLM:args>-A /scripts/ -D /scripts/ pan0</SLM:args>
 <SLM:stop stop="signal">SIGTERM</SLM:stop>