CC2564C: CC2564C integration with Android 8

Hi Rogelio, thanks for your fast response. Ok, I got your point. We're working on the replacement, and we have almost all the functionalities integrated but WB calls. Let me ask you a few things, to see if, beyond the fact that there is no official support for Android, we can reach an integration that work for us.

What is currently happening is that the fluoride stack requires us to enable BLE by including

Send_HCI_VS_LE_Enable 0xFD5B, 0x01, 0x01

command in the .bts (if we do not add it, the stack initialization fails, and it gets stuck in the .bts loading and initialization loop). On the other hand, from what we read in the controller data sheet, in order to use WBS (16ksps calls) the BLE must be disabled, because the co-processor is shared between several tasks, and can be used simultaneously by BLE and WBS).

I understand that we should do this at runtime when detecting a WB call. Is this assumption correct?

What would be the API (if it exists) to be able to send this command when detecting the call?

Is there any other way to support 16ksps calls?

Any help will be appreciated.

Regards

Mariano

Hi Mariano,

First of all congrats on porting to Android. Out of curiosity did you create your own HAL to connect with the HIDL?

Unfortunately I am not to familiar with the flouride stack and its APIs. However I agree that your approach would be the most reasonable. I assume there has to be an API to send a vendor specific command using Flouride which you could use to Disable BLE when needed. I would recommend when you create a connection with a device that will use WBS in whatever profile it is running, to disable BLE. If not its always possible to use both BLE and NBS (8khz)

Kind Regards,

Rogelio

Hi Rogelio

Ok, We will explore this path.

We basically adapted the code that we use for Wilink, introducing some minor changes, almost all worked smoothly with exception of WB calls.

When we have communication via WB, the call is not transferred to the cell phone that is linked to the chip, but is established between the 2 phones directly, and there is no activity in the I2S lines of the chip (we use the CC2564C has master on that bus). Would that be the expected behavior if at the time the call is received, BLE is enabled?

Thank you

Hi Mariano,

Yes that behavior would be expected as the coprocessor will not  be sending the proper I2S signals.

Here is a diagram that can be found in the datasheet.

Left is NBS and Right is WBS

Also here is the proper sequence when switching between the modes.

• Switching from BLE to AVPR
  1. Send HCI_VS_LE_Enable 0xFD5B, 0x00, 0x00
  2. Download (all commands of) the initscripts-TIInit_6.12.26_avpr_add-on.bts
  3. Start WBS call or assisted A2DP from the host stack.
• Switching from AVPR to BLE
  1. Send HCI_VS_AVPR_Enable 0xFD92, 0x00, 0x00, 0x00, 0x0000
  2. Download (all commands of) the initscripts-TIInit_6.12.26_ble_add-on.bts
  3. start BLE activities from the host stack.

So when you want to connect to a device with WBS and disable BLE you would have to do run this sequence on your stack.

Best,

Rogelio

Hi again Rogelio, many thanks for your response. Finally we were able to support wide band calls (verifyng that WS clock switched to 16kHz) by sending commands on demand at the time the call is going to be answered/made.

Please, let me ask one additional question. We don't use BLE at all, would it be reasonable to send the set of commands for WBS (including enabling AVPR) at an early stage, and leave that configuration unreverted while our product is running? We thought of this because it would avoid sending the commands in each call. From what we were testing, we did not find a problem with this approach, even when eventually, the MD that is paired has support only for NB, but we do not know if there is any case in which we could cause a problem.

Thank you very much again!

BR

Mariano

Hi again Rogelio, sorry for my delayed answer.

Ok, we will try this approach then.

There is one more behavior that we have observed, and that I want to ask you about. At the moment we disable BLE to be able to support WB calls, we send the following sequence of commands to the controller, according to the attached application note (by the way, I ask you if there is a different version of this document specific to cc2564c).

HCI_VS_AVPR_Enable 0xFD92, 0x01, 0x00, 0x01, 0x0000
HCI_VS_BLE_Enable 0xFD5B, 0, 0
HCI_VS_Write_CODEC_Config 0xFD06, 3072, 0x00, 16000, 0x0001, 1, 0x00, 0x00, 16, 1, 0x01, 16, 1, 0x00, 0x00, 16, 17, 0x01, 16, 17, 0x00, 0x00
HCI_Write_Voice_Setting 0x0063
HCI_Vs_Wbs_Associate 0xFD78, 0x1
HCI_Setup_Synchronous_Connection 1, 0x1f40, 0x1f40, 0xE, 0x0063, 0x02, 0x03c8

The commands have the desired effect, but nevertheless analyzing the response that comes from the controller, we see that the HCI_VS_BLE_Enable command responds with a 0x0C, equivalent to command disallowed. Do you have any idea what could be the reason why we received that response?

Regarding your question about the stack and the need to have BLE enabled, I actually didn't express myself correctly. The crash occurs due to a failure in the validation that is done in the stack, when the AOSP tries to call some methods that require support for BLE. It is not a problem of the stack itself, but of the integration.

One more time, thanks for tour support

BR

Mariano

3617.CC256x Advanced Voice and Audio Features - Texas Instruments Wiki.pdf

Hi Mariano,

Mariano Caballero said:

The commands have the desired effect, but nevertheless analyzing the response that comes from the controller, we see that the HCI_VS_BLE_Enable command responds with a 0x0C, equivalent to command disallowed. Do you have any idea what could be the reason why we received that response?

I would try disabling BLE before enabling AVPR.

Mariano Caballero said:

(by the way, I ask you if there is a different version of this document specific to cc2564c).

I believe a lot of this information found its way into the datasheet. Section 6.4.4

https://www.ti.com/lit/ds/symlink/cc2564c.pdf 

And there is also this VS command guide

https://www.ti.com/lit/an/swra751/swra751.pdf 

That will explain the parameters of each VS command.

Mariano Caballero said:

Regarding your question about the stack and the need to have BLE enabled, I actually didn't express myself correctly. The crash occurs due to a failure in the validation that is done in the stack, when the AOSP tries to call some methods that require support for BLE. It is not a problem of the stack itself, but of the integration.

I see, could you send me the necessary changes done in the AOSP to get the device to run? I've had quite a couple of questions on how to get started and this could help answer them.

Kind Regards,

Rogelio

Hi Rogelio,

your recommendation of swapping the sending order of the HCI_VS_BLE_Enable and HCI_VS_AVPR_Enable commands worked right. After making that change, the response to both commands is HCI_SUCCESS (0x00), which is the expected value.

There is one more thing that I had not noticed before, which is that apparently we are not receiving any response to sending the HCI_Setup_Synchronous_Connection command. Our command is formed with the following data

Command Opcode:  0x0428

Connection handle:  0x0001 (2 bytes)

Transmit bandwidth: 0x00001F40 (4 bytes)

Receive bandwidth:  0x00001F40 (4 bytes)

Max latency:             0x000E (2 bytes)

Voice setting:            0x0063 (2 bytes)

Retransmit effort:      0x0002 (2 bytes)

Packet type:              0x03C8 (2 bytes)

The question is, should this command also send a success (or any other response)? What caught our attention is that using the HCI Tester, we don't see that there is a Wait_HCI_Command_Complete_Event associated to this command (as there is for the rest of the them). This command doesn't appear in the cc2564c documents, because it's not a VS command but a standard HCI one, and in the documentation that we was searching on the web, we couldn't find any clue about what response should be expected after sending this command (if any response can be expected). Do you have some information about expected behavior?

Once again, thank you very much for your support.

BR

Mariano

Perfect Rogelio, thank you very much!

Regarding the HCI_VS_WBS_Associate and HCI_Setup_Synchronous_Connection commands and their counterparts HCI_Disconnect and HCI_VS_WBS_Disassociate, do you consider it necessary to perform the associate and disassociate for each call, or can it be done once, and reused as long as the hfp is not disconnected?

BR

Mariano