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: CC2564: HCI down and TI logger shows ERROR: Data Abort !!!, Link Register: 0xe10f0004

Part Number: CC2564
Other Parts Discussed in Thread: STRIKE

Hello experts,

We are facing what it seems to be a firmware bug on the CC2564.
It occurs this problem while keeping the multi connections(6 - 10 connections) for BLE and performing LE scan.
Then TI logger shows errors:

157956520 03:06:45.111 +0:01:06.450 ERROR: Data Abort !!!, Link Register: 0xe10f0004
157956521 03:06:45.111 +0:01:06.450 ERROR: Data Abort !!!, Link Register: 0xe10f0004
157956522 03:06:45.112 +0:01:06.451 ERROR: Data Abort !!!, Link Register: 0xe10f0004
157956523 03:06:45.112 +0:01:06.451 ERROR: Data Abort !!!, Link Register: 0xe10f0004

Beyound this point, the chip does not answer to HCI commands. This is reproductible on many of our boards embedding the CC2564 and may occur after half days of continous normal operation.
Then we seem this problem is recovered by chip reset only. We cannot tolerate this recovery method.

Our boards use:

OS : Linux 3.10
BTS file: initscripts-TIInit_6.7.16_bt_spec_4.1.bts/initscripts-TIInit_6.7.16_ble_add-on.bts

Please find the attached log cc2564b_hangup_issue.zip.zip

Any help on this matter would be highly appreciated,

Best regards,

cc2564b_hangup_issue.zip

  • Hi Masahi,

    Are all connections the device has using the same role (peripheral or central)? Please confirm the role of the device for each connection. 

    Also, what is your connection interval for all the connections? How many data packets are you sending between intervals?

    Jesu

  • Hi Jesu,

    The CC2564 on our board works on central role only.

    Then connection interval is 120ms when it occur the reopened problem and all connections use same interval.

    The interval of data transferring is not so short. This mean 1 or 2 packets in interval.

    Cloud you please check the attached log. Maybe it will be your reference and help.

    Thanks and best regards,

  • Hi Jesu,

    You have any update or any advise?

    Thanks and best regards,

  • Hi Masahi,

    Sorry for the delay - I am dealing with many tasks currently. I took a quick look at the logs and nothing immediately stood out to me. The connection interval is long enough so I don't think there's a throughput issue. So you could consistently reproduce this issue as long as you have at least 6 active connections correct? Is there any consistency in the failure in regards to timing or when a certain process in the system is taking place? 

    Jesu

  • Hi Jesu,

    Thanks for your reply.

    > So you could consistently reproduce this issue as long as you have at least 6 active connections correct? 

    Yes, we can reproduce this issue consistently.

    > Is there any consistency in the failure in regards to timing or when a certain process in the system is taking place? 

    When this issue occurs, it tends to occur immediately after sending an "LE Create Connection"(OPCODE=0x200D)" or "LE Create Connection Cancel"(OPCODE=0x200E) command for host to CC2564 by UART.

    Thanks and best regards,

  • Got it thanks. Do you mind running a quick test... Could you disable all data transmission and just keep the connections active, do you still get this problem? If you still get this problem I will have to reproduce this on my side so I may debug further. Please confirm if disabling all data transmission between all peripherals and central still causes this problem to rule out the possibility of a throughput issue.

    Also, out of curiosity, are you running on custom HW? 

    Jesu

  • Hi Jesu,

    Thanks for your quick reply.
    I see, I will try to check the reproducibility of this issue according to your suggestion.

    BTW, I have already attached the logs that got by your logger tool, then I got the log information as below.

    157956520 03:06:45.111 +0:01:06.450 ERROR: Data Abort !!!, Link Register: 0xe10f0004
    157956521 03:06:45.111 +0:01:06.450 ERROR: Data Abort !!!, Link Register: 0xe10f0004
    157956522 03:06:45.112 +0:01:06.451 ERROR: Data Abort !!!, Link Register: 0xe10f0004
    157956523 03:06:45.112 +0:01:06.451 ERROR: Data Abort !!!, Link Register: 0xe10f0004

    Which problem does this log mean to occur in the CC2564 chip?

    I use the custom H/W. That is BLE gateway device.

    Thanks and best regards,

  • Hi Masahi,

    The log lines you reference above could indicate some kind of FW crash but it's too early to tell. I want you to try the test I mentioned above to isolate the possibility of a throughput issue. If you could maintain all connections when peripherals don't send data that would indicate a throughput issue where our device does not have enough bandwidth to maintain all connections and incoming data. 

    Have you tested these connection with one of our CC2564 boards?

    Jesu

  • Hi Jesu,

    We have checked this issue to use 3 boards. Then, all of them occurs this issue.
    As we try to reproduce this issue according to your suggestion, it could reproduce them.
    The attached log is one by using your CC256x Logger app. Please help to check.

    Your F/W hang up when it happen the throughput performance?
    If yes, we think that we have to control the BLE transmission to avoid this issue.
    Please advise the solution.

    <Our functional requirements>
    1. LE Scan continuously
    2. up to 10 simultaneous connections (But, characteristics R/W is not so many.)

    Thanks and best regards,AutoSave Session 01 - #0079.zip

  • Hmm. I thought you said this issue occurs with 6-10 connections. In the log you sent I see you only create 3 connections. Are you saying the issue is also occurring with 3 connections now? If so we might have to think of a different approach here. Please confirm.

    Jesu

  • Hi Jesu,

    We seem CC2564 have 6 connections when it occur the issue at this time.
    However, CC2564 may lose some connections after it occurs.
    Anyway, we think that the log acquired by TI CC256x Logger knows the fact.

    Thanks and best regards,

  • Masahi, it is difficult to understand what is going on. Initially I thought the problem on the CC2564 occurs when you have 6-10 connections as I quote you below:

    It occurs this problem while keeping the multi connections(6 - 10 connections) for BLE and performing LE scan.

    On your last comment you mentioned:

    We have checked this issue to use 3 boards. Then, all of them occurs this issue.

    Are you saying here that you get the same issue with 3 connections instead of 6-10? In the last log you provided I see you only created 3 connections. Please confirm yes or no as this will change my testing requirements. 

    My apologies but you're English is difficult to understand sometimes and I'm just trying to get the details right. 

    Jesu

  • Jesu,

    Sorry for my poor English.
    Certainly it looks like you have 6 connections when the problem occurs.

    We seem certainly CC2564 have 6 connections when the problem occurs.
    There is a possibility that the previously sent log is incorrect, so reattach all logs.
    Please advise.

    Thanks and best regards,

    logs-1.ziplogs-2.ziplogs-3.ziplogs-4.zip

  • Hi Masahi,

    Thank you for providing the logs. It appears I will have to test this myself. Before I do that, please also let me know the size of the packets you are sending. If I recall correctly your connection interval is 120ms and you are sending 1 or 2 packets per peripheral between intervals? let me know thanks.

    Jesu

  • Hi Jesu,

    Thanks for yuor reply.
    In this time, our software did not transfer any data to the connected peripherals.
    However, of course we think that connection events are sent and received by each other.

    <Occurrence conditions>
    1. Continuous LE scan
    2. Keeping BLE connection and reconnecting BLE connection when disconnect
    3. No Transfer any user data excluding connection event.

  • Hello.

    Thank you for providing this information.

    I currently have 4 boards I need to get 3 more to start my test. COVID has made it a bit difficult for me but I should have the rest soon. I will keep you updated.

    Jesu

  • Jesu,

    Thanks for your reply.
    Please take care for COVID-19.
    We will wait for your update.

    Thanks and best regards,

  • Hi Masahi,

    I will finally get the rest of the boards today. I will be able to begin testing early next week.

    Jesu

  • Hi Masahi,

    Quick question, why do you have scanning enabled if the device is acting as a central? Please verify the cc2564 device is strictly operating as a central for all 6+ BLE connections you are making. To my understanding, you should only be advertising as a central when you want a BLE peripheral to discover you to connect. The BLE peripheral must be scanning to discover the central so I am confused why you are scanning. 

    I don't get problem with 6 active BLE connections while operating as a central.

    EDIT: Ignore that strike through comment. Confusion on my part. I mixed the two roles by accident.

    Jesu

  • Hi Jesu-san,

    Our production require to keep the multiple connections (max 10 connections) with peripheral devices.
    So it have to detect new device while keeping connections.

    Firstly, we want to know the causes as below.

    157956520 03:06:45.111 +0:01:06.450 ERROR: Data Abort !!!, Link Register: 0xe10f0004
    157956521 03:06:45.111 +0:01:06.450 ERROR: Data Abort !!!, Link Register: 0xe10f0004
    157956522 03:06:45.112 +0:01:06.451 ERROR: Data Abort !!!, Link Register: 0xe10f0004
    157956523 03:06:45.112 +0:01:06.451 ERROR: Data Abort !!!, Link Register: 0xe10f0004

    Why occurs this problem in CC2564? Then we have the solution to avoid this issue or not.

    Thanks and best regards,

  • Hi Masahi,

    I found this E2E from a customer who supported a similar issue a while back. I'm checking internally to see who worked on this and what was the problem. Hopefully I find something. 

    In the meantime, have you tried testing this with higher connection interval and supervision timeout for all BLE connections? 

    Jesu

  • Hi Jesu-san,

    We found 6 connections in the log which we have already provided to you.

    2020-07-10 13:15:26.278 connection_handle : 0x407
    2020-07-10 13:15:26.560 connection_handle : 0x405
    2020-07-10 13:15:26.872 connection_handle : 0x403
    2020-07-10 13:15:27.159 connection_handle : 0x402
    2020-07-10 13:15:27.425 connection_handle : 0x404
    2020-07-10 13:15:27.722 connection_handle : 0x401

    Thanks and best regards,

  • Have you tried extending connection interval and supervision timeout to see if problem goes away?

    By the way, quick update on the old thread. The engineer who supported this issue a while back is no longer with us. I'm checking with another engineer internally. 

    Jesu

  • Jesu-san,

    Thanks for your information.
    We have extended the connection interval to 120ms. That's a slow enough number.
    We can not accept more time. Because this settings relate the throughput.
    Then, supervision timeout relate the loading? Because we have not adjusted it.

    Thanks and best regards,

  • Hi Masahi. We have been investigating this internally with some direct customers who report the same issue. Please give us time as this issue has been ongoing for a while. Let's take this offline. I will message you directly on E2E if I have any updates.

    Jesu