CC2564MODA: I2S interface not getting active on incomming calls

Hi,

here are some additional information about our findings.

Once we're in the faulty situation (call is established and signalized by the module, but I2S is not providing audio data to the external DSP), we can recover the I2s operation if we change the audio routing on the phone from bluethooth to local and back to bluetooth.

From earlier investigations I have learned that the phone cuts with this action the SCO connection towards the CC2564MODA when switching back to the phone and re-establishes the connection when switching back to the CC2564MODA.
In this situation, we're not touching the configuration of the module from our side.

It seems to me, that swiitching the audio channel at the beginning of the incoming call interferes somewho with the configuration done when a incoming call is signalized and we're preparing the I2s channel.

We tried already to configure the I2s at the earlies possible point in time and that seems to improves the situation, but does not adress the root cause.
Hopefully the logger trace can reveal some more information about the root cause.

Best regards,
Adalbert

7522.extSCOReroute.zip

Hi Adalbert,

Thank you for the additional information, I will take a look at the logs and let you know if I find anything. In the meantime, I think we are on the right track with configuring I2S as early as possible. Please see the attached PDF on properly enabling/disabling A3DP. Do you know what parameters you are using for PCM?  CC256X Advanced Voice and Audio Features.pdf

Hi Daniel,

we're using the HCI_VS_Write_CODEC_Config (0xFD06) and HCI_VS_Write_CODEC_Config_Enhanced (0xFD07) commands to configure the PCM interface.

Here's the data we're using when switching to telephony mode:

0xFD06:
8kHz frame sync rate, 50% duty cycle
RAW: 8101 00 401f0000 0000 01 01 00 1000 0100 00 1000 0100 00 00 1000 1900 00 1000 1900 00 00
0xFD07:
RAW: 00 1000 2000 00 00 00 01 00 00feaf00 00 00 00 00 01 00 00feaf00 00 00

Up to now we're not using WBS, because the attached DSP does not yet support that. So, we don't use the Wbs Asscociate command yet.

Best regards,
Adalbert

Hi Daniel,

thanks a lot for the document. We didn't know that document yet.

Up to now we implemented our software based on educated guesses we made by reading state diagrams in the bluetooth specification. We'll implement the suggested changes and perform some tests.

Regarding the stream open command: Currently I don't know the efforts/possibility to get the response of the async command. Is there another way to check if the stream open command is executed? E.g. a vendor command?

A general question about the available documents for this controller/controller family:
The document you sent to us and also documents we received in the past seem to come from a TI wiki page, which is no longer accessible.
Is that content available elsewere in the web meanwhile?
Is it possible to get all the documents realated to our module? That could help us to review the implementations we made so far and to avoide running into further problems.

Best regards,
Adalbert

Hi Adalbert,

You could possibly use the HCI_COMMAND_COMPLETE_EVT that is returned to ensure the asynchronous event has been executed, without knowing your host stack perhaps there is an interrupt where you can increment the number of commands completed to know when the stream has been opened?

On the documents end, we are currently working on getting the TI wiki pages turned into technical documents and uploaded for public access. While this may be frustrating, please leverage E2E where needed and we will help to the best of our ability until we can bring the documents to ti.com.

Hi Daniel,

that would great to get the documents back online.
Regarding the asynchrounous event: Thanks for your suggestions on this. We're using bluez version 5.62 on linux.

Best regards,
Adalbert

Hi Daniel,

investigations are indicating, that there's in deed an issue with evaluating the event messages.

On sending the commands using hcitool, the tool is waiting for events to be returned but it seems it does not verify that the event matches to the command it sends. That's a point we'll try to adress first because that causes situations, where new commands are sent before the old one is answered by an event message.

Another question: We recieved some time ago the documentation about the vendor specific commands of the module. It's called "CC256x VS HCI Commands".
Is there a more detailed information about the response codes, the channel/stream commands replying?
The document we have shows only 0x00 an 0x1-0xff as possible results without delivering further information about the codes.

Best regards,
Adalbert

Hi Adalbert,

To my knowledge the only verbose response codes are those associated with the general hardware, please see the table below which is also included in the same document you mentioned: CC256x VS HCI Commands

Hi Daniel,

I've seen this table, but I have some doubts that this is the correct table. The results seem to make no sense.
I just realized that logger itself also does not use this table to decode the errors returned.

It seems it's using the standard error code descriptions from the BT core specification, Vol 1, Part F. Another strong indication is, that I get error codes from some commands with exceed the range of 0x0d.

Meanwhile we reworked our software in a way that it's now waiting reliably on the corresponding events for each of the vendor commands sent.

However, we still have situations where the audio of a call is missing.

I would be interrested in more detailed documentation about the interaction between host and CC2564 firmware. Is there e.g. some special timing or action required in case an connection request for the SCO channel is received?

Best regards,
Adalbert

Hi Adalbert,

Unfortunately we do not have more detailed documentation regarding SCO channels. As far as pertinent information the only things that come to mind are the CC256X Advanced Voice and Audio Features.pdf and list of Vendor Specific Commands CC265x_VS_HCI_Commands.pdf