Bluetooth headset routed over USB on Freerunner: why we need it and what problems i faced

[Paul Fertser]

Hi,

Preface: all this stuff doesn't apply to A2DP (high-quality
uni-directional sound playback), it works over USB HCI regardless of
routing configuration.

Following information is based on AN107 [1] (CSR, 2002, describes SCO
configuration for BC-01b and BC-02-External) and experience.

Our devices are using a more recent version, BlueCore4-ROM, with
firmware build name "odj_4hci_rom_bt2.0_19p2_0503071059_encr128
2005-03-07". The chip name suggests that we can't upgrade firmware via
DFU so we'll have to live with that one anyway. Still this chip has
some EEPROM area where various parameters are stored (called "ps keys"
for some reason).

How it works now: currently all CSR chips (BT adapters) installed on
freerunners and gta01s (based on a small IRC survey) are
pre-configured to route SCO data over PCM interface, connected to the
WM8753's BT DAI. This allows to use BT headsets for GSM calls provided
a reasonable routing inside WM8753 is used. This was tested and works.

Alas there're some usecases where this scheme can't be employed,
notably using BT headset for VoIP. Also one may want to use his BT
earpiece to do voicenotes or recording his GSM conversations. There
are probably much more possibilities where routing SCO over HCI can be
desired. One may argue that tricky routing inside WM8753 can give SoC
access to the signal, but as far as i understand (and that was
confirmed in discussions with Joerg) that is not possible given
hardware we have.

What i tried:

Installed bluez 4.30 on my laptop with a broadcom bluetooth
chip. Paired with a cheap bluetooth earpiece using simple-agent from
test. Tried to play a test wav (8000 Hz, S16_LE, mono) with hstest. It
worked, that is the headset connected and i heard the sound i
expected.

Then i compiled the same bluez version on freerunner and repeated the
procedure. Got no sound and sco packet counter (seen in hciconfig -a
output) didn't increase. hciconfig hci0 revision showed "SCO mapping:
PCM", that was obviously not what i expected. To change that bccmd
psset mapsco 0 is supposed to work, but for unknown reasons it
didn't. So i added

csr_write_pskey_uint16(dd, 4, CSR_PSKEY_HOSTIO_MAP_SCO_PCM, 0x0000, 0); 

call to hciconfig instead and run it once. After that this setting
permanently changed to "SCO mapping: HCI". Power-cycled the chip and
after that the sco counters started to grow. Still i got no sound
(though everything else seemed to work as expected).

I gathered debug logs from bluetoothd and hcidump for both cases
(working laptop and not-working freerunner) and contacted Johan
Hedberg of BlueZ project. He said he found no oddities in FR's log and
that it should work. Also he ensured me that we can issue any HCI
commands without bluetoothd interfering, that will be needed if we
finally get HCI routing to work to temporarily switch to PCM
(according to the AN).

To the best of my knowledge this SCO routing behaviour is not only
chip-specific, but also firmware-specific, so i can't see how to move
any further now. The logs are accessible from [2].

[1] http://case.cs.mnsu.edu/NSM%20Technology/141_HCI%20Implementation%20on%20BlueCore%20(AN107d).pdf
[2] http://people.openmoko.org/joerg/PaulFerster/
-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav at gmail.com