CC2652R: Advertising stopped after 1 week of normal functioning (E-lock)

Update:

The customer has found a known issue EXT_EP-9874 (sir.ext.ti.com/.../EXT_EP-9874) in the BLE5 stack release note, which related to the stopped advertising. Could this affect the SDK3.10.00.53?

The customer wants to do some research of this bug to find if it could be the cause of their problem, in the description of the bug, it says "3.Open the HCI Tester and run the enclosed script that will perform connection with invalid parameters", however the script has no where to be found. Please give some hint to reproduce the behavior, thanks!

BR,

Shuyang

Not sure if this is a bug in SDK but maybe try to enable advertising every 5 minutes on the device to workaround this.

Any update please?

BR,

Shuyang

Hey Shuyang,

I apologize for the delay here, we're all just coming back from the holidays.

I'm slightly skeptical that the bug ticket mentioned is the cause of the hang on the BLE5 stack. Can the customer provide sniffer logs when the issue occurs? This way we can analyze the connection request and events prior to the device hanging. Like you mentioned, the issue does not lock up the device entirely so this may not be a memory related issue. For this reason, I'm not sure there's much we can do to "expedite" debugging without more information.

There are some bug fixes in later SDKs that may have resolved this issue, as of right now I'm not aware of any open unresolved hang issue like you described.

From the BLE side, what customizations/stack settings is the customer using? I.e. connection interval, supervision timeout, etc. What custom modifications were made that differ from the out of box example?

Hi Ammar,

Thanks for the reply especially during the holidays. The customer is trying to get the debugging log and sniffing log, since this problem takes a long time to happen (about a week in customer's test) and it is not 100% chance to be reproduced, the customer may need a few days to provide more detailed logs. Now we are suggesting the customer to observe the RF output and the log around the advertising enable and disable code to verify the broadcast, if it is related to memory, do you have any advice for the debugging method we can use to catch the bug?

As for the bug ticket mentioned before, the customer still wants to do a little research of it to rule out the possibilities. Do you happen to have the HCI tester script described in the ticket? The script is not attached in the link. Or if there's other way to reproduce this issue using BTool or other tools, please kindly let me know.

Thanks again and wish you a happy new year!

BR,

Shuyang

Hey Shuyang,

There are a few things we can try. To rule out a memory issue, the customer can enable HEAPMGR_METRICS with the Elock connected. There's some more detail in our User's Guide here: https://dev.ti.com/tirex/content/simplelink_cc13x2_26x2_sdk_4_30_00_54/docs/ble5stack/ble_user_guide/html/ble-stack-5.x-guide/debugging-index.html#debugging-common-heap-issues

Initially I must've misread the post. Now that I revisit it, there is a possibility the bug ticket is related. Here are things we can try to expedite the issue:

• Increase the connection rate (maybe connect/disconnect every 1 min or so)
• To rule out a memory leak, increase the advertisement and scanning intervals

Just to clarify, is the E-lock a BLE only Elock? What project was this based on? I would like to verify if this is a DMM enabled project or not.

The issue seems to be resolved in the v4.30 SDK. Is the customer open to updating their project to the latest SDK?

Hi Ammar,

I just found that the link in the previous post was incorrect, apology for that. I will post the correct link again as below:

https://sir.ext.ti.com/jira/browse/EXT_EP-9874

The ticket is "Simple Peripheral application stopped advertising after an unsuccessful connection", which is the bug customer wants to test. In the steps given by the ticket it says "3.Open the HCI Tester and run the enclosed script that will perform connection with invalid parameters...", however the script is nowhere to be found. Could you please help find the script or equivalent steps to reproduce this bug?

Thanks for the tips to debug the memory issue, I will suggest the customer to use the HEAPMGR_METRICS. And please be noted that the customer already tried increasing the connection rate, but found no difference than the original connection rate.

The project is BLE only, based on BLE ProjectZero. The customer is trying with the latest SDK, but they still wants to know the root cause of the issue to prevent further fails.

Thanks!

BR,

Shuyang

Hey Shuyang,

I apologize, I forgot to comment on the script side. The script is an internal tester script with quite a few dependencies. I don't think we'll be able to provide it (it won't function correctly without the dependency). I can try to get the script running on my end if needed. If it's possible to translate this script into something simpler, I will do so. Please note that this may take some time given the upcoming New Years holiday. For now, let's focus on testing on the latest SDK first.

As for the resolution of the bug ticket, the issue was in stack. When multiple advertisements were enabled, an incorrect callback was triggered resulting in unexpected behavior. This was only fixable in the source code of the stack which is provided as a library.

EDIT: I will be out of office until 1/4/2021, so my responses will be delayed until then.

Hi Ammar,

I found that the ticket is referring to CVE-2019-19193 with the same description, if that is the case I have found a hex file to reproduce it here.

Thanks for your support, and I will come back when the customer has more details for analysis.

BR,

Shuyang