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.

CC2564C: Question about MIC Failure

Part Number: CC2564C
Other Parts Discussed in Thread: CC2564

Hello!

We've encoutered a problem with a random LE disconnection due to MIC Failure during normal operation. It is hard for us to detect the exact reason from this, but we suspect there might be related to invalid hopping sequence numbering. We also see that there is some strange sequences going on in the HCI log. After the MIC failure, we get an unexpected HCI_LE_Connection_Complete from the device withchanged LE address, without having enabled the advertising. Later we are getting a second HCI_LE_Connection_Complete for the same device, which looks quite weird. 

We'd like some clarification on these sequences. However, as we and the customers are working under NDA I am not keen on sharing the logs in the public forum. Hence, I've been recommended to request a private channel for the exchange of logs in this case.

Regards

Erik Almqvist

  • Hi Erik,

    I will try to assist the best way I can but it may be difficult without logs. Before diving in could you tell me what SDK version and service pack are you using for the CC2564C? Regarding the MIC issue, it would help if you give me some background as to what is going on in the system (e.g. mode, profiles, number of devices). Is your device operating as a central? Also is the MIC issue related to a pairing failure?

    A peripheral device could connect to a device that's not advertising if it already knows the address. Make sure you have no devices in your environment that are trying to connect to your device.

    Jesu

  • Hi!

    There is no related pairing or encryption procedures going on, the MIC Failure occurs during normal ATT operation, there is also no ongoing pairing or encryption procedures. There is support for BR/EDR and the same device is connected over this transport. The connected unit is an iPhone 7, and we are acting as peripheral towards this device. As far as I know, it's not possible to connect without the peripheral is advertising in this scenario. The central could skip the scanning if it knows the address though.

  • Hi Jesu

    Please refer to the attached file. There are two files: hci dump log and the service pack we used.

    We applied cc2564c chip in our HU product. The HU will connected with remote iPhone with HF profile, A2DP profile and AVRCP profile. At the same time, we also have a BLE link with the same iPhone to use GATT profile to tran/receive some user data.

    As Erik said, can you find out something about this issue? And do you need another somethings else?

    Thanks!

    hci_and_bts.7z

  • Hi Jonathan, Erik,

    So just to confirm, you are using custom HW correct? Also, I noticed in the initialization script you have some additional RF related commands. What is the reason for this?

    As an attempt to start isolating the problem, could you attempt to test this with one of our CC2564C boards and confirm whether or not this issue is still present?

    Jesu

  • Hi Jesu

          We modified the RF related commands to obtain high power level for BLE, and to control the BR/EDR output power level.

          I have one CC2564C board but without a MCU to drive it. 

          Could you analyse this problem from the log? If you need firmware log, then I can capture one for you.

           Thanks!

  • Hi Jonathan,

    I can take a second look at the logs with a team member but at this stage I have higher confidence we are dealing with a HW/RF issue instead of a SW issue. This is why it would be really helpful if you can run the same test with the CC2564C board that you have. This will quickly isolate the problem for us. I will get back to you next week but in the interest of time you should also investigate the possibility of a HW/RF issue by running your setup with known working HW (CC2564C board).

    Jesu

  • Hi 

       I had a test with EVB board with same software, but the issue happened with that EVB again.

      So it seems like it's not a FW/RF issue.

       Then could you please research this issue in another side?

      thanks.

  • Hi Jonathan,

    Thank you for verifying this. 

    I'm not sure what the problem could be with the information at hand. I did not extract much information from the air capture and .BTS file you provided. Please provide FW logs and I will check with my team to try to narrow down the problem.

    -Jesus

  • Hi Erik, Jonathan,

    I have reviewed the FW logs with a teammate. Although we didn't see disconnects due to MIC failures in the latest logs (8-03) we did see the connections failed due to timeouts on both BT classic and BLE. We are concerned the bandwidth usage on the CC2564 might be too high since shortly after establishing the BLE connection both connections are dropping. Could you try disabling page scanning and inquiry scan to see if that fixes the issue? You can also try increasing the connection interval, latency and timeout for BLE.

    Jesu

  • Hi Jesu

           Yes, the log sent you on 08-03 was not MIC failure but timeout failure. Then I tried to reproduce the MIC case, but could not reproduce that case unfortunately. 

           From the log you can know that the timeout failure is another issue we must fix. I will try to disable page scanning and inquiry scanning when connected and to increase the connection interval, latency and timeout for BLE link; then watch if it works or not.

          But at the same time, could you find out why cannot create any connection after the issue that timeout failure happened? I think it is a critical issue for us because the user cannot make a connection.

         Thanks

         

  • Hi Jonathan,

    But at the same time, could you find out why cannot create any connection after the issue that timeout failure happened? I think it is a critical issue for us because the user cannot make a connection.

    This may also be related to the bandwidth issue but I'm curious about the "Assert: no buffer for...." log line I'm seeing. I'm waiting to hear back from a teammate to get some more context on that. I will update you if it's worth mentioning.

    Jesu

  • Hi Jonathan,

    Have you made any more progress here? Please keep me updated.

    Jesu

  • Hi Jesu

         I applied these steps( disable inquiry scan, page scan and adjust the BLE link parameters). Then I found that the two links can be stable more time over 3 hours. But sadly, then the two links broken. 

         And I concern that not all remote device support to modify the BLE link parameters. 

      

  • Hi Jesu

        Please refer to the attached HCI log. You can find out that the two link broken then cannot make another BR/EDR connection.

    And can you give me some advice about how to adjust the BLE link parameters? It seems that the remote cell phone do not support that feature to adjust the BLE link parameters? And about the disconnection and cannot make another connection, any update about that?

    1663.hci_dump.7z

  • Hi Jonathan,

    And can you give me some advice about how to adjust the BLE link parameters?

    In GAP_LE_Create_Connection you can set things like min/max connection interval, slave latency, etc... If you want to update the link parameters after the connection is established you can use GAP_LE_Connection_Parameter_Update_Request API. Please refer to GAPAPI.h and for more details on these functions. There is also examples of how each of these are used and more in the SPPLE demo. It is also useful to check the GAP_LE_Event_Callback in the example to see how it responds to certain BLE events. I think this is what you're asking. Does this answer your question? 

    And about the disconnection and cannot make another connection, any update about that?

    For disconnects on the BLE side, the FW logs you sent me last time it looks like you stopped advertising after the disconnects and never enable it again. Below is a screenshot of the last advertise enable command sent. Make sure BLE advertising is enable before you try to establish the connection from the iPhone.

    For the BT classic connection attempts you keep getting page timeout reason codes for the failed connection attempt. This would indicate that the remote device is not responding to the page request sent which explains the timeouts. I would recommend here you verify the iPhone is connectable before sending a connection request per BT core spec. What I'm seeing in the previous logs also correlates with the latest HCI dump. It shows our device sending connect request and does not show response from the iPhone (packet 20251). 

    I did not see you include FW logs, only HCI dump. 

    Jesu

  • Hi Jesu

        I captured new logs for you. Please refer to the attached file.

       The content shown below based on this logs.

       1. From the HCI log, frame 652, you can find that we used HCI_LE_Connection_Update to update the LE link parameters. But chip replied  that HCI command failed with error code( Unsupported Remote Feature/Unsupported LMP feature). So the parameters for that HCI command is right? We did not use host stack from TI but from cybercom.

      2. From the HCI log, frame 2945 and frame 2947, you can find that the two link( BR/EDR and LE link) disconnected with error code timeout. Why for this?

      3. After the two link disconnected, we tried to create another BR/EDR connection at frame 2954. After sent HCI command HCI_Create_Connection, we cannot receive any response for this command for ever!  So it's a fatal issue for us.0812.7z

  • Hi Jonathan,

    Thanks for including FW logs + HCI dump and referencing the packet lines in your explanations. This is helpful.

    1. I correlated packet 652 in HCI log to line 9938 in the FW logs. Error code 0x1A means that the remote device does not support the feature you are requesting but I don't think you are doing anything wrong here. The parameters you are providing seem to fall within spec. 

    2-3. This issue is similar to the last logs.

    I think this issue may be related to an internal mailbox overflow that handles certain events. You may have too much going on across your connections that is causing this overflow. This would make sense since when you changed your scanning and advertisement settings you got longer connection times before it broke again. 

    Jesu

  • Hi Jesu

      1. Then we cannot modify the BLE link parameters.

       2. About the timeout disconnection issue and the issue cannot create another BR/EDR link, I think TI should fix the two problem.

          There is no much time for us, please fix it as soon as possible.

  • Hi Jonathan,

    There might be a memory leak issue but I think it's related to the bandwidth problem I mentioned earlier. The CC2564 FW assumes that the mailbox will never overflow but I think your application may be causing it to overflow because it may be demanding too much from the CC2564. You already saw better performance when you minimized scanning and inquiry.

    1. How often are you sending data packets over each connection interval?
    2. If you are transmitting many packets it would be helpful to see if the performance changes when minimizing the number of packets sent. Could you perform this test?

    Also,

    We did not use host stack from TI but from cybercom.

            3. You are not using Bluetopia? Have you tried to see if this problem can be reproduced using Bluetopia? 

    If changing data packets does not provide any meaningful results the next step would be for me to try to reproduce your problem here on one of our EVMs. If you are not using Bluetopia this will take more time for me to setup because you cannot provide code to reproduce quicker.

    Jesu

    1. How often are you sending data packets over each connection interval?

    Local device connected with remote iPhone, then local device use A2DP to play music and one app on the iPhone sends some control signaling to local device.

    Is it too much more data to transfer? I think it is normal use case.

             2. If you are transmitting many packets it would be helpful to see if the performance changes when minimizing the number of packets sent. Could you perform this test?

    How many bytes every milliseconds does the controller accept?

             3. You are not using Bluetopia? Have you tried to see if this problem can be reproduced using Bluetopia?      

     With the HCI log and the FW log, I think you can find out the root cause: the HCI log includes all the data between CPU and the chipset.

  • Hi Jonathan,

    If that is all you are doing I don't think this is too much data. I'm currently working on reproducing this issue. Please let me know if the setup below is a sufficient use case:

    • CC2564C connected to a phone via BT and BLE
    • CC2564C acting as BLE master sending GATT data
    • CC2564C acting as A2DP sink playing audio

    Please note I can test this with iPhone 11 and Samsung S10. I don't have an iPhone 7. Have you tested this with Android to rule out the possibility of an interoperability issue?

    Jesu