- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi there
Our Bluetooth Stack BTstack (http://bluekitchen-gmbh.com) runs without any additional configuration with the Broadcom USB Bluetooth modules (e.g. the 20702).
Using the firmware patchrams contained in the WICED SDK, I was also able to bring it up on the BCM 43438, too.
What's missing now is, how to configure the chipset to route SCO data over HCI for testing? (I assume that it is routed to the I2S bus).
Assuming that is possible, how is flow control done? The Write SCO Flow Control Enable command returns the error Unknown HCI Command.
Best regards,
Matthias Ringwald
BlueKitchen GmbH
Solved! Go to Solution.
- Tags:
- sco hci
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Finally got SCO over HCI working with the USB BCM 20702!
hci_bcm_write_sco_pcm_int(1, 0, 0, 0, 0) needs to be sent after the stack has bootet up. Before, I did sent it before or after the patch ram file. The warm boot/reset seems to reset the SCO config the same way as the baudrate and the BD_ADDR resets.
My breakout board with a BCM43438 doesn't work right now, but I guess there's a good chance that SCO data will be routed via HCI there as well.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
With some luck using Google, I found this tool by Broadcom to configure their modules on Linux
that indicates that there is this command
uchar hci_write_sco_pcm_int[] = { 0x01, 0x1C, 0xFC, 0x05, 0x00, 0x00, 0x00, 0x00, 0x00 }; |
with 5 parameters. The first one is
sco_routing with the following values: 0 for PCM, 1 for Transport, 2 for Codec and 3 for I2S,
Sending it with sco_routing = 1 before or after the patchram did not seems to make a change (didn't get any SCO packets).
Is there some kind of "Warm Reset" to confirm the change? (e.g. CSR requires an HCI Reset after setting a configuration param like baud rate)
Best
Matthias
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is typically no flow control for SCO/eSCO traffic. It supposed to be synchronous. Host will receive certain amount of bytes in a packet every several milliseconds and needs to send back to the device exactly the same number of bytes.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello victorz. Thanks for the hint on using the received data as a means of synchronizing outgoing data. Didn't think about that.
On TI's CC256x chipsets, the Write SCO Flow Control command works and it reports each processed packet, allowing the stack to send the next ready SCO packet.
I guess that's only relevant for SCO over HCI, which I use for simple examples - while most designs will use I2S/PCM anyway.
Any idea how to properly "confirm" the route over HCI, especially for USB?? (see follow up post)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Finally got SCO over HCI working with the USB BCM 20702!
hci_bcm_write_sco_pcm_int(1, 0, 0, 0, 0) needs to be sent after the stack has bootet up. Before, I did sent it before or after the patch ram file. The warm boot/reset seems to reset the SCO config the same way as the baudrate and the BD_ADDR resets.
My breakout board with a BCM43438 doesn't work right now, but I guess there's a good chance that SCO data will be routed via HCI there as well.