CC2340R5: After a while device doesnt work properly with Central and few other strange problems

Hello,

Thank you for reaching out. I am sorry to read you ran into these issues.

The first element I would recommend is to update the SDK version to use SDK 7.40 - https://www.ti.com/tool/download/SIMPLELINK-LOWPOWER-F3-SDK. I am recommending this as several bugs were fixed since SDK 7.10.

Then, in order to provide assistance on the three elements mentioned,

- Could you please comment whether you have access to a Bluetooth sniffer? It would help us understanding the issues.

- For #3, can you comment whether pairing and bonding are enabled?

- If doable, can you provide the minimal changes to implement to the basic_ble example in order to reproduce the issues?

Best regards,

Thank You Clement, firstly will upgrade to 7.40 and get back after some testing. 

- Please suggest a sniffer tool for CC2340 devices, don't have one right now

- We are not using pairing and bonding. In Bond Manager settings Bonding is unchecked.

- Will test with the latest SDK and if we continue to see issues, will provide a basic_ble application with our minimal application integration.

Sounds good! Let us know your progress!

When it comes to the Bluetooth sniffer, I like to use the products from Ellisys (quite widely used in the industry). Alternatively, you can leverage the Bluetooth sniffer tool provided by TI - SmartRF Sniffer (https://software-dl.ti.com/simplelink/esd/simplelink_lowpower_f3_sdk/7.40.00.64/exports/docs/ble5stack/ble_user_guide/html/ble-stack-5.x-guide/debugging-index-cc23xx.html#smartrf-sniffer-agent-setup)

Best regards,

Hello Clement, have migrated to new SDK and continuing the testing. The issue 1 about Central device (Android 13, Samsung A8 tablet) stops working and only flight mode ON/OFF or hard reset recovers is happening more frequently now especially during night time. We usually get GATT error (133) before this happens. Since our device is rooted, now we have done a fix to do flight mode ON/OFF automatically upon receiving error 133 with disconnect. This behaviour on our central device only happens with CC2340R5 boards and not on our legacy CC2640R2F boards. Will share our syscfg settings and also our app_peripheral, simple gatt profile files with you for a review. Also want to confirm, since CC2340R2F is a single core chipset, any chances of packet losses by receiver? Is this device suitable for large data transfer like more than 150 bytes and even more in some cases?

Hello Clement,

Please review the SysCfg, and our other customizations in app folder including simple gatt frofile and let us know if we are missing something. 

Open Drive Link

[removed by Clement]

Hello,

Thank you for providing these elements - for privacy reasons, I have removed the link from your previous message.

Here are a few remarks:

• The maximum number of connection seems to be set to 0 in your SysCfg file (parameter ble.maxConnNum cannot be found which means it is interpreted as 0). At the same time, it looks like you form a connection.
  To change this, I recommend to use the SysConfig GUI (BLE>General Configuration > Max Number of Connections). Alternatively, you can add the line "ble.maxConnNum = 1;" at line 83 of your.syscfg file.
  I highly recommend fixing this before continuing the tests.
• In general, the Android GATT error 133 is pretty generic and not that easy to interpret as it regroups very different causes. On this one, a Bluetooth sniffer would really help.
• The CC2340R5 supports well large data transfers - it is tested up to 251 bytes per packet (which is the maximum allowed by Bluetooth spec). Also, I have a personal project where I use it for audio transfers. So, on this point I am not too worry :)

I hope this will help,

Best regards,

Thanks, but the Max Number of Connections is set 1 in syscfg, not 0. 

Clement, here is some feedback after some testing today. The data is transmitted from single device running on Android Tablet, ver 13. Every 15 seconds around 16 bytes of data and every 25 seconds around 170 bytes of data. After around 1000 connection/disconnection cycles, issue number 1 happened where central device is unable to connect anymore, Bluetooth On/OFF doesn't help. Only hard reset or Flight Mode ON/OFF recovers the central device. Issue number 2 as well occurred where the board is advertising, connects, but doesn't receive data at simple gatt profile or at the application, even from the different mobile device. Power cycle recovers the board. I have logs for both cases from central device side (Android App), please suggest how to share it with you. 

Hi,

Thank you for the additional details. In general, you can share the logs here on E2E if you are comfortable with this.

If I may additional pieces of feedback

1- The connection interval selected (7.5 ms) seems too short compared to the data transfer ("Every 15 seconds around 16 bytes of data and every 25 seconds around 170 bytes of data") I would rather go for ~100 ms. The value you have selected should not be a problem per say but may lead to unnecessary power consumption.

2- I think we agree the issue is pretty likely on the CC2340R5 side. For this reason, I would recommend to run more debug operations on the CC2340R5. Among others, you could consider reproducing the issue with the debugger attached - or connect the debugger to a running target. Then check if the device is crashed (probably not the case here) or if the heap memory is exhausted. Crashed / spin-looping devices can be identified by stepping in the code using the debugger. The heap memory usage can be checked using the runtime object viewer (see here).

For issue #1

After the issue reproduces, I understand the connection establishment fails. Have you check if a BLEAPPUTIL_LINK_TERMINATED_EVENT event is passed to the CC2340R5 application layer in that case? If yes, it would be interesting to see which error is reported there.

Also, would resetting the CC2340R5 allow to recover? Or is the only way is to hard reset or Flight Mode ON/OFF the tablet?

For issue #2

Here the issue makes me think to a heap memory exhaustion - see before.

Best regards,

Hello Clement, the issue number 1 occurred and I have connected the debugger, we are receiving BLEAPPUTIL_LINK_TERMINATED_EVENT as attached. The only way to recover is reset or flight mode on/off on tab (not sure if this happen immediately or after couple of terminations though, but eventually central device gets to this state, right now do not wish to test this by resetting board before your further advice on this). Please suggest what are the parameters to monitor now and also potential fix to recover this situation. 

Hello,

When receiving the BLEAPPUTIL_LINK_TERMINATED_EVENT, you also receive a pointer to a BLEAppUtil_msgHdr_t structure (pMsgData) that can be cast to a gapTerminateLinkEvent_t structure. The "reason" field of the same structure should help getting a better understanding of issue.

Here is a short code snippet showing the same. You can also reference the file app_connection, which, by default, implements the same.

        case BLEAPPUTIL_LINK_TERMINATED_EVENT:
        {
            gapTerminateLinkEvent_t *gapTermMsg = (gapTerminateLinkEvent_t *)pMsgData;
            
            volatile uint8_t reason = gapTermMsg->reason
            

I hope this will help,

Kind regards,

The reason is 62 (LL_STATUS_ERROR_CONN_FAILED_TO_BE_ESTABLISHED?) in this specific case, normal disconnect is 22 (LL_STATUS_ERROR_HOST_TERM)

Hi,

Connection termination reason 0x3E (62) corresponds to "Connection Failed To Be Established".

Connection termination reason 0x16 (22) corresponds to "Connection Terminated By Local Host"

Here is what the spec says about 0x3E (BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 1, Part F, §2.59):

A "Connection Failed To Be Established" reason should be sent by the peripheral in the two following cases:

• case 1: If connection created but not established, and received a request with incorrect access address
• case 2: If connection created but not established for Direct Advertisement, but no data packets received ==> Are you using Direct Advertisements? (I don't think so when reviewing your code but let me know if I have missed it)

Case 1 could also explain why the device remains connectable by other phones. What are your thoughts?

In order to get a way to reproduce, can you be more specific on how many days (you said "few days") are required to reproduce? Also, if not already done, could you consider resetting the device periodically (like every 6 hours) during your experience to see if the issue still reproduces?

Best regards,

Hello Clement, probably it is case1 as you mentioned as we are not using direct advertisements (our setting is - Connectable and scannable undirected)

Let me test again on number connection cycles it takes to reproduce the case as it seemed to have happened quite early this time with actual application operations, also we do have a reset strategy, but have disabled in our test setup, once issue happens again will enable and test. 

Meanwhile, issue 3 likely happened and when this happened, i don't see  Generic Access Profile during characters discovery, please see the 2 pics. This is probably when reset doesn't recover the board. In todays case was, log functions were enabled, board was idle for almost a day, debugger probably disconnected abruptly..

Please provide any insight into this and also how to detect this and recover within code. 

BR

Ravi

Hi Ravi,

Ravichandra Reddy said:

On the two screenshots you have shared, I mention the device is "Disconnected". Could the behavior be caused by a disconnection during the GATT table discovery process?
Have you tried to hook up a debugger to the device and see if some interesting elements could be collected there?

When it comes to detect this issue, I recommend first looking at the device state (as suggested on previous line).
Alternatively, I guess you could consider detecting it from the phone side. You could then either send a reset command to the device over Bluetooth LE (assuming the connection works) or prompt the user to reset the device.

I hope this will help,

Best regards,

Hello Clement, 

"In order to get a way to reproduce, can you be more specific on how many days (you said "few days") are required to reproduce?"

- Issue this time occurred after connections disconnection cycles of probably around 120~150 on 2 occasions. These include 1 connection cycle transferring 16 bytes data and 1 connections cycle transferring around 170 + 16 bytes of data (in 2 different characters)

Even with the periodic board reset, the issue occurs. Looking forward to hear from you to proceed further..

Also regarding above case, the screen shot was taken from BLE scanner, one case while it was connected, in another case it was already disconnected by the controller.

BR

Ravi