• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 1484 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2564: Unexpected HCI error creating outgoing connection after power-cycle

Matthias Ringwald
Expert 1475 points
Part Number: CC2564

In a customer project, we see the following behaviour using a CC2564B with Service Pack 1.6:

  1. we start up the Bluetooth stack and connect to smart phone
  2. we power-cycle the embedded device and try to connect to the same phone again
  3. this time we get a "Connection Complete Event" with Error 0x0b "ACL Connection Already Exists".

After doing a power cycle and sending a HCI Reset, I don't expect any ACL connections to exist. I'll attach a .pklg, which can be opened with Wireshark that captures the HCI trace after power on.

Unfortunately, it doesn't look like there's a way to 'disconnect' this zombie connection. FWIW, the smartphone does not yet know that the CC2564 was power-cycled and shows 'connected'.

Any ideas? Could you try to re-produce this issue with your stack. I can help if you want to try with BTstack, too.

Thanks, Matthias

HCI Log file: cc2564b-connection-exists.pklg.zip

  • 0
    TI__Mastermind 29301 points

    Hi Mattias,

    Matthias Ringwald said:

    In a customer project, we see the following behaviour using a CC2564B with Service Pack 1.6:

    1. we start up the Bluetooth stack and connect to smart phone
    2. we power-cycle the embedded device and try to connect to the same phone again
    3. this time we get a "Connection Complete Event" with Error 0x0b "ACL Connection Already Exists".

    Could you please provide the CC256x Bluetooth firmware logs (User's Guide can be found here) for this scenario? We can take a look at the logs to understand if the device is indeed getting reset or not.

    Matthias Ringwald said:
    FWIW, the smartphone does not yet know that the CC2564 was power-cycled and shows 'connected'.

    The Bluetooth firmware logs will provide some relevant details about the internal states of the CC2564 in this scenario. Moreover, the smartphone may take a while (time equal to the LSTO value of the connection) to indicate the link loss if the CC256x is abruptly reset without sending LMP_detach to the phone.

    Best regards,

    Vihang

  • 0 in reply to Vihang Parmar
    Expert 1475 points
    Hi Vihang. Thanks for your response. I'm not familiar with the CC256x TxDebug log, although I've worked with the series since the first revision.
    I did manually press the Reset (nShutdown button) on the BOOST-CC2564MODA and the attached HCI logs show HCI Reset and response as well as service script upload. I don't see how the Controller is not getting reset.

    If this doesn't help, I'll try to get the firmware logs from the device next.

    Thanks.
  • 0 in reply to Matthias Ringwald
    TI__Mastermind 29301 points

    Hi Matthias,

    While I trust your test procedure, I trust the firmware logs even more. Please provide the CC256x firmware logs (as described in the User's Guide) for this scenario. Thanks!

    Vihang

  • 0 in reply to Vihang Parmar
    Expert 1475 points

    Haha... that's what I usually tell my customers as well (show me my logs or there's no issue..)

    Ok, on the Booster Pack, the TxDBG already has a level shifter for 3.3V, so I was able to just connect an  FTDI 232R board there without soldering..

    Log is attached. Is there a way to pause the log while the logger is running? I've pulled the jumper wire, but a 'pause' button would be more convenient.

    Browsing over the log: is it possible that the CC2564B is behaving correctly and sends an connection request to the smartphone, which didn't realize yet the link is dead, and rejects the incoming connection as it is already connected? I'll need to check with our customer if they can send an HCI disconnect before powering off, but that's notoriously hard in the general case.

    cc2564b-connection-exists.lgr.zip

  • 0 in reply to Matthias Ringwald
    TI__Mastermind 29301 points

    Hi Matthias,

    The log capture did not include any data from the HCI/LMP viewer port of the logger, so I could not verify the LMP transactions. But I did get some information from this capture.

    Matthias Ringwald said:
    Browsing over the log: is it possible that the CC2564B is behaving correctly and sends an connection request to the smartphone, which didn't realize yet the link is dead, and rejects the incoming connection as it is already connected?

    It is definitely possible and this seems to be the case from the BT logger only traces. In the cc2564b-connection-exists.lgr capture,

    Trace # Comment
    29999 CC256xB is reset by toggling the nSHUTD pin
    30382 CC256xB service pack download and host stack initialization is complete
    30383 Host sends the HCI_Create_Connection command to CC256xB to reconnect to 
    30409 and 30413 The CC256xB sends LMP_features_req and LMP_features_req_ext PDUs to the remote device. Both PDUs get answered by the remote device. These PDUs are sent during the connection procedure and they can also be sent after the connection is established.
    30418 The CC256xB sends the LMP_Host_connection_req PDU to the remote device in order to initiate LMP later connection. This request gets rejected by the remote device. So it looks like the remote device thinks there was a link loss and the connection was recovered before the Link Supervision Timeout (LSTO).

    The proper way to resolve this is to send HCI_Reset before powering off the CC256xB device. The HCI_Reset will cause the CC256xB to send LMP_detach PDU to all active connections and the remote phone will know that the BT link is terminated. So when the local device comes back couple of seconds later, the remote device doesn't think that it is still the previous connection.

    If sending the HCI_Reset before the power off is not possible, you may want to reduce the LSTO of the connection so that the BT link on the remote device timeout faster. For example, you can set the LSTO to 5 seconds and make sure the local device waits atleast 5 seconds before re-initializing and re-connecting to the same remote. 

    Hope this helps.

    Best regards,

    Vihang

  • 0 in reply to Vihang Parmar
    Expert 1475 points

    Hi Vihang

    Thanks for checking the logs and confirming my (late) suspicion. If the remote rejects the connection, the CC2564B behaves correctly, that's great.

    We did try reducing the Link Supervision Timeout to 5 seconds, which is sufficient for the smartphone to detect the link loss itself before the device tries to connect again.

    Thanks!