CC2564MODN: A3DP Source Demo

Thank you for your reply, but I have to admit I haven't got much further.

How can I check what is wrong with my stream endpoint? Does this stream endpoint mean the headset (i.e. the sound sink) or the PCM interface where I feed the audio data into the CC2564 (i.e. the sound source)?

I see from the code that I do not yet get to the point where I would configure the PCM interface as the input where the sound comes in (ReconfigureA3DPStream -> initializeAudio). But this call comes after my problematic call to AUD_Query_Stream_Channel_Information in the original A3DP Source Demo code, so I wouldn't expect the not-yet-configured PCM to be my problem.

If the problem is on the headset side, any hints on what to diagnose? This seems pretty much the same as the BT speaker used in the swru580 User's Guide. Or could it be that the headset is using a different profile (HSP vs A2DP) and this is causing AUD_Query_Stream_Channel_Information to fail?

Hi Martin,

It could very well be that the headset is trying to use a different profile but because A2DP is very common I'd doubt it; especially since using another CC2564C board did not work. In this case the endpoint being referred to should be on the local side, rather than the PCM interface it moreso refers to the internal bluetooth service.

There are a couple things I can think of:

• Have you made any changes to the demo code or are you running it as is? Do you have access to the terminal? If so, I'm assuming there are no errors in the prior initialization functions such as AUD_Initialize_V1?
• Rather than initializing the connection from the Sink (headset) side, could you use the demo's OPENSINK command that calls AUD_Open_Remote_Stream() and let me know if there is any difference in behavior.
• If all else fails, do you have access to the debug pin on CC2564C? Would you be able to gather an HCI log using BT Logger Tool?
  • This log would contain information that may be valuable in helping us isolate the problem.

Hi Daniel,

Thanks for your valuable feedback.

- I have imported the original demo code again and made only the necessary changes to adapt it to our HW & used the CC256XB.h patch from v1.8 package. The problem persists. I do have access to the terminal. I see no errors prior to the one described.

- I've always used the "opensink" command to connect the headset. I force the headset to start re-pairing, then run "inquiry" to find its index and finally run "opensink <indx>". Please see a sample output. I added some more diagnostic output, denoted by # at linestart:

OpenStack().
Bluetooth Stack ID: 1
A3DP Source Feature enabled.
Device Chipset: 4.1
BTPS Version  : 5.1.1.1
PLAT Version  : 1.0
App Name      : STM32-TI-BT-SRC
App Version   : 0.2
Project Type  : 6
FW Version    : 7.42
Local BD_ADDR: 0xD8B673934117
EIR Data Configured Successfully (Device Name STM32-TI-BT-SRC-934117).
A3DP Endpoint opened successfully.
Class of Device: 0x100428.
Supported formats:
   Frequency: 44100, Channels: 2, Flags: 0
   Frequency: 48000, Channels: 2, Flags: 0
   Frequency: 48000, Channels: 1, Flags: 0
   Frequency: 44100, Channels: 1, Flags: 0

******************************************************************
* Command Options: Inquiry, DisplayInquiryList, Pair,            *
*                  EndPairing, PINCodeResponse, PassKeyResponse, *
*                  UserConfirmationResponse,                     *
*                  SetDiscoverabilityMode, SetConnectabilityMode,*
*                  SetPairabilityMode, SetBaudRate               *
*                  ChangeSimplePairingParameters,                *
*                  GetLocalAddress, GetLocalName, SetLocalName,  *
*                  GetClassOfDevice, SetClassOfDevice,           *
*                  GetRemoteName, OpenSink, CloseSink, Play,     *
*                  Pause, Help                                   *
******************************************************************

A3DP+SRC>inquiry

A3DP+SRC>
Inquiry Entry: 0xD8B67394547E.

A3DP+SRC>
Inquiry Entry: 0x000D44D18552.

A3DP+SRC>
  Result: 1,0xD8B67394547E.
  Result: 2,0x000D44D18552.

A3DP+SRC>opensink 2

AUD_Open_Remote_Stream success.

A3DP+SRC>
atLinkKeyRequest: 0x000D44D18552

GAP_Authentication_Response success.

A3DP+SRC>
atIOCapabilityRequest: 0x000D44D18552

Auth success.

A3DP+SRC>
atIOCapabilityResponse: 0x000D44D18552
Capabilities: No Input/Output

A3DP+SRC>
atUserConfirmationRequest: 0x000D44D18552

Auto Accepting: 403903

GAP_Authentication_Response success.

A3DP+SRC>Un-handled Auth. Event. // I checked that the event type here is 11 = atSecureSimplePairingComplete

A3DP+SRC>
atLinkKeyCreation: 0x000D44D18552
Link Key Stored.

A3DP+SRC>
atAuthenticationStatus: 0 for 0x000D44D18552

A3DP+SRC>
etEncryption_Change_Result for 0x000D44D18552, Status: 0x00, Mode: Enabled.

A3DP+SRC>
etAUD_Signalling_Channel_Open_Indication
BD_ADDR:  0x000D44D18552

A3DP+SRC>
etAUD_Stream_Open_Confirmation
Status:      0
BD_ADDR:     0x000D44D18552
MediaMTU:    895
# StreamChannelInfo: InMTU=1100, OutMTU=0, LocalCID=1, RemoteCID=0 // This is the state after calling AUD_Query_Stream_Channel_Information()
# AUD_Query_Stream_Channel_Information=-1006 // This is the value returned by AUD_Query_Stream_Channel_Information()

A3DP+SRC>
etAUD_Remote_Control_Open_Indication
BD_ADDR:     0x000D44D18552

A3DP+SRC>

- I recorded an HCI log covering the time interval shown in the terminal above. You can find it here temporarily: https://ufile.io/w92yfako, or I let you indicate another way to share the file with you.

HI Martin, 

You can reply to this thread and while drafting the response, click Insert > Image/Video/File > and select the HCI log from your file system.

Just in case, I have sent you a friend request on the platform with my email address. If for some reason the above method does not work, please send the HCI log there as I am unable to open your link on the TI network.

Hi Daniel,

I can't attach this kind of file type. So I renamed it *.lgr -> *.png. I sent the original by e-mail too, just in case.

Edit: hmm, while renaming made the file upload possible, it seems this still doesn't enable to download it.

Hi Martin,

Reuploading the log for anybody who looks at this thread later on: source-demo-log.lgr

Based on the terminal output you gave there doesn't seem to be an issue there. Going through the log, while (what I believe to be) the patch is being uploaded to the device, the command complete for AVPR_Enable is dropped. Can you confirm that you are using the latest service patch with the AVPR Add-on for CC2564B? CC256XB-BT-SP Driver or library | TI.com

Additionally, it seems the headset you are using enables a much older version of LMP, associated with Bluetooth 3.0. Would you be able to test your setup with a newer headset or update the firmware?

Regards,

Daniel

Hi Daniel,

- I am using the CC256XB.h patch from the v1.8 package available from your link. This has been the case from the very beginning.

- FYI, I also see HCI_Protocol_Viewer_Message_Was_Dropped_Event when running the sink demo, i.e. the one that works.

- This is the only headset I have at my disposal, and I couldn't update it. However, when I replace the headset with the sink demo board, I get a newer LMP version but the problem persists:

- I would like to recheck one thing: at the stage where I get this error (when calling AUD_Query_Stream_Channel_Information), it doesn't matter yet where the sound data will come from, right? I.e. we are only establishing the stream on the BT stack level here, the configuration of the audio comes later and can't be the cause of this error?

- Is there any chance of getting hold of the source code of the library that is giving this error? I understand that it's difficult for you, and impossible for me, to debug this without getting more information from the code that returns this error. However, I've seen (e.g. here) that other people have managed to get this demo to work and I'd like to move forward.

Hi Martin,

This is the proper program flow for A3DP, taken from this document in case you haven't seen it. It may contain some background information that could help you understand your issue: 0285.CC256x Advanced Voice and Audio Features.pdf

As you can see from the diagram and also on the function's description below, it only fetches the L2CAP Channel Information, any information relating to setting up the codec (PCM/I2S) comes after opening the stream. This might be a failure in setting up a proper ACL connection hence it cannot fetch the L2CAP information?

Though that would be odd considering there appears to be some sort of traffic over ACL:

Perhaps there is something that needs to change in the base level HCI settings? You could try initializing the program in a UART mode other than HCILL, slowing down the UART etc. Unfortunately I cannot provide further feedback at this time but if you have any additional questions along the way you can continue to post on E2E.

/* The following function is used to get information about the L2CAP */
   /* channels associated with this endpoint.  This function accepts as */
   /* input the Bluetooth Stack ID, the Local Endpoint ID, and the      */
   /* channel type to query.  The last parameter is a pointer to a      */
   /* buffer that is to receive the current L2CAP Channel Information   */
   /* that are being used by the specified endpoint.  This function     */
   /* returns zero if successful or a negative return error code if     */
   /* there was an error.                                               */
   /* * NOTE * This function returns an error if the specified Channel  */
   /*          Type is trNone.                                          */
int BTPSAPI GAVD_Get_Channel_Information(unsigned int BluetoothStackID, unsigned int LSEID, GAVD_Transport_Channel_Type_t ChannelType, GAVD_Channel_Info_t *ChannelInfo)

Beyond this level of detail I cannot provide the source code to you. That said, it would be more of a rabbit hole than it already is as this essentially acts a fetch function for the internal Bluetopia information. 

Hi Daniel,

I haven't given up yet, I hope you're not fed up with me.

I switched to using the A3DP Sink Demo project instead of the headset to eliminate the old LMP version issue and to get more diagnostics. I can see that the AUD_Query_Stream_Channel_Information function gets called successfully on the sink board when it connects to the source board:

SINK:

OpenStack().
Bluetooth Stack ID: 1
Device Chipset: 4.1
BTPS Version  : 5.1.1.1
PLAT Version  : 1.0
App Name      : Test-SNK
App Version   : 0.2
Project Type  : 6
FW Version    : 7.42
BD_ADDR: 0xD8B67394547E
A3DP endpoint opened successfully.
Class of Device: 0x040424.
Supported formats:
   Frequency: 44100, Channels: 2, Flags: 0
   Frequency: 48000, Channels: 2, Flags: 0
   Frequency: 48000, Channels: 1, Flags: 0
   Frequency: 44100, Channels: 1, Flags: 0

******************************************************************
* Command Options: Inquiry, DisplayInquiryList, Pair,            *
*                  EndPairing, PINCodeResponse, PassKeyResponse, *
*                  UserConfirmationResponse,                     *
*                  SetDiscoverabilityMode, SetConnectabilityMode,*
*                  SetPairabilityMode, SetBaudRate               *
*                  ChangeSimplePairingParameters,                *
*                  GetLocalAddress, GetLocalName, SetLocalName,  *
*                  GetClassOfDevice, SetClassOfDevice,           *
*                  GetRemoteName, OpenSink, CloseSink,           *
*                  RemotePlay, RemotePause, RemoteNext,          *
*                  RemotePrev, Help                              *
******************************************************************


A3DP+SNK>
atIOCapabilityResponse: 0xD8B673934117
Capabilities: No Input/Output

A3DP+SNK>
atIOCapabilityRequest: 0xD8B673934117

Auth success.

A3DP+SNK>
atUserConfirmationRequest: 0xD8B673934117

Auto Accepting: 369163

GAP_Authentication_Response success.

A3DP+SNK>Un-handled Auth. Event.: 11

A3DP+SNK>
atLinkKeyCreation: 0xD8B673934117
Link Key Stored.

A3DP+SNK>
etAUD_Signalling_Channel_Open_Indication
BD_ADDR:  0xD8B673934117

A3DP+SNK>
Unhandled AUD event: 25

A3DP+SNK>
etAUD_Stream_Open_Indication
BD_ADDR:     0xD8B673934117
MediaMTU:    800
# StreamType:  SNK
# StreamFormat:
#   SampleFrequency: 44100
#   NumberChannels:  2
#   FormatFlags:     0
# SyncSource:   1
# BluetoothStackID=1
# BD_ADDR=0xD8B673934117
# StreamChannelInfo: InMTU=800, OutMTU=800, LocalCID=129, RemoteCID=129
# AUD_Query_Stream_Channel_Information()=0
# GAP_Query_Connection_Handle()=0
# ConnHandle=1
Status: VS_A3DP_Sink_Open_Stream(): 0

 Send HCI Flow Spec for guaranteed ACL connection
# HCI_Flow_Specification()=0

 Send HCI VS DDIP for ACL priority over scans
# VS_Send_DDIP()=0
 Initialize audio with Sample Freq: 44100

 I2S configuration start f = 44100

A3DP+SNK>
etAUD_Remote_Control_Open_Indication
BD_ADDR:     0xD8B673934117

A3DP+SNK>

SOURCE:

OpenStack().
Bluetooth Stack ID: 1
A3DP Source Feature enabled.
Device Chipset: 4.1
BTPS Version  : 5.1.1.1
PLAT Version  : 1.0
App Name      : STM32-TI-BT-SRC
App Version   : 0.2
Project Type  : 6
FW Version    : 7.42
Local BD_ADDR: 0xD8B673934117
EIR Data Configured Successfully (Device Name STM32-TI-BT-SRC-94547E).
A3DP Endpoint opened successfully.
Class of Device: 0x100428.
Supported formats:
   Frequency: 44100, Channels: 2, Flags: 0
   Frequency: 48000, Channels: 2, Flags: 0
   Frequency: 48000, Channels: 1, Flags: 0
   Frequency: 44100, Channels: 1, Flags: 0

******************************************************************
* Command Options: Inquiry, DisplayInquiryList, Pair,            *
*                  EndPairing, PINCodeResponse, PassKeyResponse, *
*                  UserConfirmationResponse,                     *
*                  SetDiscoverabilityMode, SetConnectabilityMode,*
*                  SetPairabilityMode, SetBaudRate               *
*                  ChangeSimplePairingParameters,                *
*                  GetLocalAddress, GetLocalName, SetLocalName,  *
*                  GetClassOfDevice, SetClassOfDevice,           *
*                  GetRemoteName, OpenSink, CloseSink, Play,     *
*                  Pause, Help                                   *
******************************************************************

A3DP+SRC>inquiry

A3DP+SRC>
Inquiry Entry: 0xD8B67394547E.

A3DP+SRC>
  Result: 1,0xD8B67394547E.

A3DP+SRC>opensink 1

AUD_Open_Remote_Stream success.

A3DP+SRC>
atLinkKeyRequest: 0xD8B67394547E

GAP_Authentication_Response success.

A3DP+SRC>
atIOCapabilityRequest: 0xD8B67394547E

Auth success.

A3DP+SRC>
atIOCapabilityResponse: 0xD8B67394547E
Capabilities: No Input/Output

A3DP+SRC>
atUserConfirmationRequest: 0xD8B67394547E

Auto Accepting: 369163

GAP_Authentication_Response success.

A3DP+SRC>Un-handled Auth. Event.: 11

A3DP+SRC>
atLinkKeyCreation: 0xD8B67394547E
Link Key Stored.

A3DP+SRC>
atAuthenticationStatus: 0 for 0xD8B67394547E

A3DP+SRC>
etEncryption_Change_Result for 0xD8B67394547E, Status: 0x00, Mode: Enabled.

A3DP+SRC>
etAUD_Signalling_Channel_Open_Indication
BD_ADDR:  0xD8B67394547E

A3DP+SRC>
etAUD_Stream_Open_Confirmation
Status:      0
BD_ADDR:     0xD8B67394547E
MediaMTU:     800
# StreamType:   SRC
# StreamFormat:
#   SampleFrequency: 44100
#   NumberChannels:  2
#   FormatFlags:     0
# SyncSource:   1
# BluetoothStackID=1
# Data->BD_ADDR=0xD8B67394547E
# StreamChannelInfo: InMTU=1100, OutMTU=0, LocalCID=1, RemoteCID=0
# AUD_Query_Stream_Channel_Information()=-1006

A3DP+SRC>
etAUD_Remote_Control_Open_Indication
BD_ADDR:     0xD8B67394547E

A3DP+SRC>

So I started to look at where the asymmetry occurs. I see this difference in the debug logs recorded on the two boards while they boot up (up to here, they behave pretty much the same):

SINK:

SOURCE:

As you can see from the highlighted lines, I get an "A3DP: Init..." message followed by an "A3DP SINK: Init..." message on the sink board. On the other hand, I get an "A3DP: Init..." message twice on the source board while, for the sake of symmetry, I would expect the second one to be "A3DP SOURCE: Init..." or something similar.

Can you give me a hint where these messages are coming from and whether this sink-source discrepancy is expected?

Hi Martin,

Those messages are normally sent during startup while the patch is being written to and processed by the device. Because of the nature of the patch getting multiple of that event is not unexpected. For example here is the samething happening in other logs: