CC2564C: A3DP source demo, Cancel a connection request.

Elisa,
Could you please share the complete host debug logs and the CC2564C firmware logs?
Host debug logs - serial terminal output from the application MCU (like the traces copied in your question)
CC2564C firmware logs - www.ti.com/.../swau058

Best regards,
Vihang

Hello Vihang,

I took traces from the CC2564C debug pin, using TI's tool called Logger. But when I try to post them here, I get an error message that the file type is not supported.

The steps and use case I have the issue with is :

1. Reset the headset's PDL, and put it in pairing mode,

2. TI scanned for sink devices

3. Ti initiated a new connection to the selected headset. This connection was successful.

4. Powered off the headset.

5. Forgot the headset from TI

6. Powered on the headset and put it in pairing mode.

7. TI starts scanning again

8. TI discovers the headset and initiates a new connection to it.

9. It takes between 60sec to 2min to receive a connection failure message.

Please let me know how to share the file with you. THANKS!

Hi Vihang and Hari,

I've sent the logger file internally to you on Elisa's behalf.

Thank you,
Lauren Mayfield

The following are the Host debug logs, I can't post the complete file because it contains proprietary information. So hopefully this helps.
The time stamp is in msec, so the time elapsed from the connecting request, to the connection failure event is about 98sec

3218273: Connecting to 0x50190150368E via AUD... <----------------------------------------

3218279:
3218286:

3218290:

3252321:
3252327:
3252332:
3252336:
3252339:
3252342:
3252360:
3252364:
3315827: GAP_Event_Callback
3315831:
3315832: atLinkKeyRequest: 0x50190150368E <----------------------------------------
3315838: GAP_Authentication_Response success.
3316173:
3316174: etAUD_Stream_Open_Confirmation <----------------------------------------
3316179: Status: 3
3316183: BD_ADDR: 0x50190150368E
3316188: LINK KEY: 0x00000000000000000000000000000000
3316194: Connection failed.
3316203:
3316209:
3316214:

Hi Elisa,

Do, you mean the Link key is not saved on the host and so the connection failed the 2nd time? From the logs, it appears the controller is reporting back disconnect very quickly.. Do, you see the 60 sec to 2 min delay on the host?

26705 04/12/19 10:48:16.575 +0:00:00.000 0x0007BC25 0x00018980 <---- HCI_Link_Key_Request_Event
26706 04/12/19 10:48:16.575 +0:00:00.000 0x0007BC33 0x0001898E HCI_Link_Key_Request_Negative_Reply ---->
26707 04/12/19 10:48:16.575 +0:00:00.000 0x0007BC34 0x0001898E <---- HCI_Command_Complete_Link_Key_Request_Negative_Reply_Event
26708 04/12/19 10:48:16.575 +0:00:00.000 0x0007BC3C 0x00018997 LMP_not_accepted ----> Opcode = LMP_au_rand, Reason = Key Missing
26887 04/12/19 10:48:16.810 +0:00:00.235 0x0007BD04 0x00018A5F <---- LMP_detach Reason = Authentication Failure
26890 04/12/19 10:48:16.903 +0:00:00.328 0x0007BD42 0x00018A9D <---- HCI_Disconnection_Complete_Event

Thanks

Hello,

The link key does not exist anymore, because the remote device was forgotten (there was a user action to forget the remote sink)

So TI is starting a new connection request, but the remote sink replies with a Link Key request (and seems to be requesting the old key)

so TI responds with no key.

but, as you say, the host does show the disconnect message until 60sec to 2min after.

I would suggest looking in the host side for the source of the delay. The controller seems to respond fairly quickly. Is the host configured for any idle/sleep states?

Thanks

Hello Hari,
How can I check for any idle/sleep states on the host side?
At boot/initialization, we use the following function : VS_Enable_Sleep_Mode(BLUETOOTH_GetStackID(), FALSE);

aside from that,

once we call AUD_Open_Remote_Stream(BLUETOOTH_StackID, SelectedRemoteBD_ADDR, astSRC); which returns zero, which means success;
we do nothing else but to wait for the result of the connection request, that happens to print on the uart screen between 60sec to 2min later.

if the controller reports the disconnection quickly, why would the library report that result with such a big delay?

Your insight is greatly appreciated.
Cordially,
Elisa

Hi,

The low power states are specific to the MCU. For MSP432, and Idle task is scheduled and if the HCILL UART is in sleep, the MCU can enter into low power state. I am not sure, how it is handled for STM32 micro. Please, check their demo examples.

Are, you using non Os or with an RTOS?
if, you have front line technologies serial HCI sniffer, you can use to check the HCI command, result timings..

Thanks

Hi,

Regarding the MCU entering into low power state, our Principal Engineer confirms that the ST micro does not go into any type of sleep mode, and that we are not using an RTOS.

Unfortunately our sniffer does not have the ability to sniff HCI traffic.

We do disable TI's sleep mode, as I mentioned before.

Something to note is that this issue only happens with a specific brand of headsets, any other commercial headsets, the response is fairly fast.

Is it possible that TI might be re-trying to connect for that long, for some reason?

Is it with the same UE boom speaker? We, are waiting for the unit to test..

Thanks

Hello Hari,

This issue happens with Letscom U8I and Mpow headphones.

I received an email yesterday confirming the UEBoom speaker had arrived to your office, but you did not received it? 

Please confirm.

Thank you for your assistance,

We, do not have these head sets to try.. Since, it is dependent on headsets, it does not seem like a host sleep issue.. The Fw log, we reviewed earlier seem fine.. Can, you take few more with this issue to check..

Thanks

Yes, I can take more traces today.

Thank you for all your assistance.