Bluetooth HSP/HFP profiles are not working

[Dmitriy Beykun]

Hello,

I've been testing various headsets with my Wandboard Quad and Dual and cant get anything from HSP/HFP profile modes with the integrated bluetooth (A2DP works). I've tried both old 11.10 and new 12.04 images.

On 11.10 images I have: UART locks up with DMA issues ("We cannot prepare for the RX slave dma" or "We cannot prepare for the TX slave dma" - this is SDMA engine messages); Next thing whole bluetooth framework locks up, sometimes restarting bluetooth daemon helps, but still nothing works (both HFP/HSP input and output)

On 12.04 images I have: Just silence from both input and output. Audio sink connects okay, but nothing from the headset itself.

I already tried playing with /etc/bluetooth/audio.conf a bit a didnt achieve anything with public known bugs with Broadcom adapters. Also tried updating bluez/bluetooth packages to latest (didnt try to compile them myself, though).

One of my first concerns was the I2S sound bus path from BCM4330 on the module to the CODEC, was it tested working or configure right?

Hope full bluetooth functionality is in TechNexion plans and this will be tested and fixed soon.

Best Regards,

Dmitriy Beykun

[Dmitriy B.]

I confirmed that issue is I2S path - by default BlueZ uses HCI for SCO routing, which is unsupported by the BCM4329 (also makes UART DMA. the PCM (I2S) path should be used and the codec.

By default in /etc/bluetooth/audio.conf we have this:

# SCO routing. Either PCM or HCI (in which case audio is routed to/from ALSA)

# Defaults to HCI

# SCORouting=PCM

I tried setting it to PCM, but SGTL5000 doesnt accept incoming I2S connection or BCM4329 doesnt start it right, I have nothing on codec inputs.

Any ideas about how to configure these two? Broadcom has many module options available, I will try to figure out the needed settings, but any help will be appreciated.

Best Regards,

Dmitriy Beykun

[Dmitriy B.]

The missing I2S part is described here for the SGTL5000 part: http://cache.freescale.com/files/analog/doc/app_note/AN3664.pdf?fpsp=1&WT_TYPE=Application%20Notes&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation

[Dmitriy B.]

Confirmed not working in "Wandboard Quad Jellybean 4.2.2 (21 June 2013)" too. Same thing - no data transfered to or from remote bluetooth device.

[Dmitriy B.]

WRONG, but working solution:

Broadcom bluetooth devices should be initialized by this program: https://code.google.com/p/broadcom-bluetooth/source/browse/brcm_patchram_plus.c

By default, guy who did the rootfs wrote this to rc.local:

/usr/local/sbin/brcm_patchram_plus --timeout=6.0 --patchram /lib/firmware/brcm/bcm4329.hcd --baudrate 921600 --use_baudrate_for_download /dev/ttymxc2 && hciattach /dev/ttymxc2 any 921600 &

Unfortunately, this is wrong in couple places:

1. Baudrate for bluetooth emebedded in BCM4329 can be up to 3000000, why not use the maximum

2. There are no --scopcm parameter sent. I spent some hours figuring this out and came to conclusion: only the "Transport" setting is working, everything else needs extra work done, such as fixing SGTL5000. Some other rootfs images have scopcm set to 0,4,0,0,0,0,0,0,0,0, which is also wrong.

Lets fix this two issues and run:

/usr/local/sbin/brcm_patchram_plus  --scopcm=1,4,0,0,0,0,0,0,0,0 --timeout=6.0 --patchram /lib/firmware/brcm/bcm4329.hcd --baudrate 3000000 --use_baudrate_for_download /dev/ttymxc2 && hciattach /dev/ttymxc2 any 3000000 &

It will work, but you will still have two issues: UART SDMA still fails if anything is sent BOTH ways. This is unacceptable for HSP/HFP. And there is also another issue - there is something wrong with audio timings, everything seems to be recorded and played back exactly twice slower than if it be original. I suspect this is pcm rate issue, will try to figure it out. So next step is getting rid of SDMA on UART since it fails horribly: in this structure http://repo.or.cz/w/wandboard.git/blob/refs/heads/wandboard:/arch/arm/mach-mx6/board-wand.c#l662 remove SDMA flag and .dma_req_tx/rx definitions leaving it like this:

static const struct imxuart_platform_data wand_bt_uart_data = {

         .flags = IMXUART_HAVE_RTSCTS

 };

Now UART will not get stuck and HSP/HFP will work.

But yet, this is a WRONG solution - we need to find why exactly SDMA fails for bluetooth and figure out how to use AUDMUX/I2S connection provided by the PCB itself. This solution uses UART for SCO, while PCB initially was designed from reference design using I2S/PCM for SCO data. But I guess this is up to TechNexion to show if they care about they own products - I already spent many hours figuring this out, now it is up to manufacturer to fix this right way.

Best Regards,

Dmitriy Beykun