CC2564 Handsfree Connection Breaks after Power Cycle

Hi Jason,

Do you get a "atLinkKeyRequest" event in your app when you do: "OpenRemoteAudioGatewayPort()" ?
What do you respond to it? Can you try with another remote device to see if the behaviour is any different?

To answer your questions,

Does the CC2564 store Linkkey or Bluetooth address information internally? [A] No
Do we need to inform the CC2564 over HCI about LinkKeys after a power cycle? [A] No

Regards,
Gigi Joseph.

Thank you for the response Joseph.  I think I have resolved the issue, but the root-cause makes no sense...

We use simple pairing mode to avoid the need for pincodes.  However, issuing the GAP_Set_Pairability_Mode() command too early after bootup breaks the entire stack.

For example, after booting up we display the HELP screen and perform some system initialization.  Actions such as:

* Setting simple pair mode

* Loading BT Addr and LinkKeys from flash

* Registering callbacks

* Opening a HF Server

* Disabling WBS

* Setting the PCM bit rate and frequency

If I set simple pair mode too early, pairing with any device returns an authentication error 5.   There seems to be no way to recover from this aside from closing/re-opening the stack.

So I was forced to do this by hand from the console after every power up.   I was properly setting simple pair for the initial pair and opening of the HF connection.  But after the reboot I was forgetting to manually re-apply the simple pairing command.

I didn't actually think it was necessary - because we were already paired and had generated link keys.  But apparently it does matter and cell phones have issues reconnecting when this mode isn't set.

For now I have moved the set simple pair mode to the end of the initialization, which adds about a 250ms delay.  This seems to stop pairing from breaking and allows the CC2564 to re-open HF connections after a power cycle. 

I need to test this more today and will let you know if I run into any more problems with this.  Please let me know if you can provide any insight into this behavior.   Thanks!

Hi Jason,

The error (-5) indicates: "BTPS_ERROR_GAP_INITIALIZATION_ERROR". Are you sure you are not getting any error return for the previous BSC_Initialize() call? Also, please confirm if you are passing the correct "BluetoothStackID" to GAP_Set_Pairability_Mode().

Regards,
Gigi Joseph.

No, the logs show no difference there.  The only difference is the # of devices that show up on inquiry (we have a few other headsets here) and how the setpairabilitymode command is issued later in the log that succeeds.   The initialization (registering callbacks, opening the HFserver( we performing in between don't seem to be involved. 

https://drive.google.com/file/d/0B9EYwAWdSUu2X1FrSzZoQmtyTUU/view?usp=sharing

  The BluetoothStackID is set to 1 from the OpenStack call, and remains that way throughout in both scenarios according to the debugger.  If it wasn't set, the command wouldn't be able to set the pairabilitymode. 

  I'd be interested to know if a cause can be found.  It doesn't seem to exist when I run the same functional code on the MSP430. 

- Jason 

Hi Jason,

Let me check more on this and get back to you...
Btw, Authentication error 5 just indicates AUTHENTICATION_FAILURE.

Regards,
Gigi Joseph.

Hello Jospeh, just checking on if you were able to duplicate this behavior?  

Thank you,

 - Jason

Hi,

It is hard to say what is causing the authentication failure, without the sniffer logs.
But I would suggest you try with a different remote device, As I have not face any problem in pairing with my Smart phone Tiva C device

Hello Joseph,

  In response to your question -

 Do you get a "atLinkKeyRequest" event in your app when you do: "OpenRemoteAudioGatewayPort()" ?

What do you respond to it? Can you try with another remote device to see if the behaviour is any different?\

 

 

I am getting an atLinkKeyRequest event when I do an OpenRemoteAudioGatewayPort() command.  Looking at my old logs, this doesn't appear to have always been the case.  To double-check, I brought out my old MSP430 board and HFPDemo app and tested it, and am finding it behaving the same way with code back from November.   Any idea why I get this event now when I didn't before? 

 

 

Here is a log of the MSP430 board -

 

HFRE16>inquiry
Return Value is 0 GAP_Perform_Inquiry() SUCCESS.

HFRE16>
GAP Inquiry Entry Result: 0x68644BF3F460.

HFRE16>
GAP_Inquiry_Result: 1 Found.
GAP Inquiry Result: 1, 0x68644BF3F460.

HFRE16>pair 1
GAP_Initiate_Bonding (Dedicated): Function Successful.

HFRE16>
atLinkKeyRequest: 0x68644BF3F460
GAP_Authentication_Response() Success.

HFRE16>
atPINCodeRequest: 0x68644BF3F460

Respond with the command: PINCodeResponse

HFRE16>pincoderesponse 1111
GAP_Authentication_Response(), Pin Code Response Success.

HFRE16>
atLinkKeyCreation: 0x68644BF3F460
Link Key: 0x70F2EDD7D20C5DC4AC5A27FACB2376AC
Link Key Stored locally.

HFRE16>
atAuthenticationStatus: 0 Board: 0x68644BF3F460

HFRE16>openhandsfreeclient 1 3
Bluetooth Device Address: 0x68644BF3F460
Open Remote HandsFree Port = 0003
HFRE_Open_Remote_Audio_Gateway_Port: Function Successful (ID = 0002).

HFRE16>
atLinkKeyRequest: 0x68644BF3F460
Responding with Link Key.
GAP_Authentication_Response() Success.

HFRE16>
HFRE Open Port Confirmation, ID: 0x0002, Status: 0x0002.

 

Notice the opening of the port now fails.  I'm assuming because of a link key mismatch...  but why would the host regenerate link keys?  This is a pretty vanilla HFPDemo app with just a function added for the opening of the remote audio gateway. 

 

My previous logs showed behavior as follows:

 

 HFRE16>openhandsfreeclient 1 3
Bluetooth Device Address: 0x68644BF3F460
Open Remote HandsFree Port = 0003
HFRE_Open_Remote_Audio_Gateway_Port: Function Successful (ID = 0002).

HFRE16>
HFRE Open Port Confirmation, ID: 0x0002, Status: 0x0002.

HFRE16>
HFRE Control Indicator Status Indication, ID: 0x0001, Description: SIGNAL, Value: 3.

HFRE16>
HFRE Control Indicator Status Indication, ID: 0x0001, Description: SIGNAL, Value: 2.

HFRE16>
HFRE Control Indicator Status Indication, ID: 0x0001, Description: CALLSETUP, Value: 1.

HFRE16>
etHFRE_Codec_Select_Indication, ID: 0x0001 Codec ID: 2.

HFRE16>
HFRE Command Result, ID: 0x0001, Type 1 Code 0.

 

The etAuthentication case, atLinkKeyRequest case is stock sample app code :

 

 

               case atLinkKeyRequest:
                  BD_ADDRToStr(GAP_Event_Data->Event_Data.GAP_Authentication_Event_Data->Remote_Device, BoardStr);
                  Display(("atLinkKeyRequest: %s\r\n", BoardStr));

                  /* Setup the authentication information response      */
                  /* structure.                                         */
                  GAP_Authentication_Information.GAP_Authentication_Type    = atLinkKey;
                  GAP_Authentication_Information.Authentication_Data_Length = 0;

                  /* See if we have stored a Link Key for the specified */
                  /* device.                                            */
                  for(Index=0;Index<(sizeof(LinkKeyInfo)/sizeof(LinkKeyInfo_t));Index++)
                  {
                     if(COMPARE_BD_ADDR(LinkKeyInfo[Index].BD_ADDR, GAP_Event_Data->Event_Data.GAP_Authentication_Event_Data->Remote_Device))
                     {
                      Display (("Responding with Link Key.\r\n"));
                        /* Link Key information stored, go ahead and    */
                        /* respond with the stored Link Key.            */
                        GAP_Authentication_Information.Authentication_Data_Length   = sizeof(Link_Key_t);
                        GAP_Authentication_Information.Authentication_Data.Link_Key = LinkKeyInfo[Index].LinkKey;

                        break;
                     }
                  }

                  /* Submit the authentication response.                */
                  Result = GAP_Authentication_Response(BluetoothStackID, GAP_Event_Data->Event_Data.GAP_Authentication_Event_Data->Remote_Device, &GAP_Authentication_Information);

 

Any help you can give me would be much appreciated.  

 

 

- Jason

 

 

 

 

Hi,

I think the "Status: 0x0002" is because of using the wrong port number, It looks like "Unknown Connection Identifier" error.

Hello again,

How does one determine the correct Port # to Open?


I've read posts on using the SDP Service Discovery to determine the correct Port #, but am having trouble understanding the results. I even tried looping through Open_Remote_Audio_Gateway calls using Ports 1-99 without any success. Log of the Discovery is below.


For Android phones and BlueGIGA modules Port 3 always works.

On Apple devices Port 3 apparently used to work based on my logs - but then I'd hit the Codec Negotiation bug. Something changed after I removed the Support_Codec_Negotiation bit to fix this, and Port 3 no longer works. Perhaps an iOS update occurred in between...

On Apple devices Port 1 connects, but stalls. The devices are unable to complete the Service Level Connection. The L2CAP connection exists, but nothing else.

On Apple devices Port 2 connects and then disconnects after a few seconds. A Service Level Connection is never established.



Essentially my problem is the phone can connect to the CC2564 and open a HF connection with single SCO audio. But if the phone goes out of range or the CC2564 power cycles, the CC2564 is unable to re-open the HF connection. The user must manually do it from the iPhone.

Sounds like I'm real close! Thank you.


- Jason

HFRE16>servicediscovery 1 12
SDP_Service_Search_Attribute_Request(Audio gateway) Success.


HFRE16>
SDP Service Search Attribute Response Received (Size = 0x000A)
Service Record: 1:
Attribute ID 0x0000
Type: Unsigned Int = 0x0000111F
Attribute ID 0x0001
Type: Data Element Sequence
Type: UUID_16 = 0x111F
Type: UUID_16 = 0x1203
Attribute ID 0x0002
Type: Unsigned Int = 0x00000000
Attribute ID 0x0004
Type: Data Element Sequence
Type: Data Element Sequence
Type: UUID_16 = 0x0100
Type: Data Element Sequence
Type: UUID_16 = 0x0003
Type: Unsigned Int = 0x08
Attribute ID 0x0005
Type: Data Element Sequence
Type: UUID_16 = 0x1002
Attribute ID 0x0006
Type: Data Element Sequence
Type: Unsigned Int = 0x656E
Type: Unsigned Int = 0x006A
Type: Unsigned Int = 0x0100
Type: Unsigned Int = 0x6672
Type: Unsigned Int = 0x006A
Type: Unsigned Int = 0x0110
Type: Unsigned Int = 0x6465
Type: Unsigned Int = 0x006A
Type: Unsigned Int = 0x0120
Type: Unsigned Int = 0x6A61
Type: Unsigned Int = 0x006A
Type: Unsigned Int = 0x0130
Attribute ID 0x0008
Type: Unsigned Int = 0xFF
Attribute ID 0x0009
Type: Data Element Sequence
Type: Data Element Sequence
Type: UUID_16 = 0x111E
Type: Unsigned Int = 0x0106
Attribute ID 0x0100
Type: Text String = Handsfree Gateway
Attribute ID 0x0301
Type: Unsigned Int = 0x01
Attribute ID 0x0311
Type: Unsigned Int = 0x002F

Hurgh... It appears the forums won't let me delete posts anymore. Tried with 2 different computers and using IE and Chrome, with no luck.

Another poster was discussing this same issue at the same time apparently, and your help to him also helped me get past this issue. It appears the Apple devices often change the Port. I must have just been getting lucky that 3 was working!

3 months of toil, multiple reads through the BT standards and specifically Googling for this topic just didn't get me to the nugget of information that the last int in Atrribute ID 4 is the Port ID.

Attribute ID 0x0004
Type: Data Element Sequence
Type: Data Element Sequence
Type: UUID_16 = 0x0100
Type: Data Element Sequence
Type: UUID_16 = 0x0003
Type: Unsigned Int = 0x08 <--- This is the Port # !

So glad that is behind me. Though, the original problem with issuing the SetPairabilityMode command too early still exists - though it was unrelated to this Port issue. Their occurring at the same time is what confused me.

Thank you both for the help!

- Jason

Hi,

I hope the below image help, If not you can check the sdptool to have better understanding

Hi jason,

Did you find your issue? "On Apple devices Port 1 connects, but stalls. The devices are unable to complete the Service Level Connection. The L2CAP connection exists, but nothing else."

I have the same behavior in my side. It really help me if you find something new.

Thank you in advance.

Denis

Hi jason,
sorry for my last post, it was my error, I find my answer, I used the wrong port number.
"
Attribute ID 0x0004
Type: Data Element Sequence
Type: Data Element Sequence
Type: UUID_16 = 0x0100
Type: Data Element Sequence
Type: UUID_16 = 0x0003
Type: Unsigned Int = 0x08 <--- This is the Port # !
"
Denis