CC2640R2F: BLE and phone disconnecting after first time connection

Hi Saurav,

Thank you for posting on the E2E forums. I have notified a colleague to come comment on this.

Best,

Nima Behmanesh

Hi Saurav,

I haven't seen the sniffer logs you have mentioned, however, per your description, it looks like the CC2640R2F is behaving as expected. I mean, the CC2640R2F close the connection when receiving the terminate link from the mobile phone.

This makes me rather think to an issue with the way the mobile app works and/or some misunderstanding between the mobile app and iOS. In both cases, the experts answering on this forum may not be able to answer your question. I would rather recommend to contact the iOS support.

Thank you for your understanding.

Kind regards,

Hi Clément,

I have added the sniffer log and also some of my analysis, please look into it and let ous know the insights.

.

Regards,

Saurav

Hi,

Thank you for providing the sniffer logs. I will review them and come back to you on Monday.

Best regards,

Hi Saurav,

I am running into issues to open the file you have provided. Could you please tell me which tool should be used?

Best regards,

Hi Clément,

The TI's packet sniffer SW can be used for seeing the logs.

Please find the attached document also for link of SW and steps for setup.

Sniffer setup.docx

.

Regards,

Saurav

Hi Saurav,

Thank you for the guidance... I managed to make a confusion between PACKET SNIFFER and PACKET SNIFFER 2... As we say in French "shoemakers children are the worst shod".

Here are a couple of observations:

• at packet #1449, I see the peripheral sending a Start_Encryption_Req then everything is properly encrypted
• the last proper packet sent out by the peripheral is #1462. After this, the central (phone) only sends out packets that are never acknowledged.
• I guess the retries occur until the connection timeout. Then the peripheral gets back advertising

It would be nice to see on the CC2640R2F device what is the connection termination cause.

Best regards,

Hi Clément,

While doing testing from our side we are suspecting that the BLE is getting reset and that's why the connection is getting terminated.

So, will you please let us know how to get the reason for a reset?

.

Regards,

Saurav

Hi,

The reset source can be found using the following code:

#include <driverlib/sys_ctrl.h>

int main()
{
  uint32_t resetSource = SysCtrlResetSourceGet();

  //...
}

Please refer to sys_ctrl.h for details on the values returned by the function:

//*****************************************************************************
// \name Return values from calling SysCtrlResetSourceGet()
//@{
//*****************************************************************************
#define RSTSRC_PWR_ON                 (( AON_PMCTL_RESETCTL_RESET_SRC_PWR_ON    ) >> ( AON_PMCTL_RESETCTL_RESET_SRC_S ))
#define RSTSRC_PIN_RESET              (( AON_PMCTL_RESETCTL_RESET_SRC_PIN_RESET ) >> ( AON_PMCTL_RESETCTL_RESET_SRC_S ))
#define RSTSRC_VDDS_LOSS              (( AON_PMCTL_RESETCTL_RESET_SRC_VDDS_LOSS ) >> ( AON_PMCTL_RESETCTL_RESET_SRC_S ))
#define RSTSRC_VDDR_LOSS              (( AON_PMCTL_RESETCTL_RESET_SRC_VDDR_LOSS ) >> ( AON_PMCTL_RESETCTL_RESET_SRC_S ))
#define RSTSRC_CLK_LOSS               (( AON_PMCTL_RESETCTL_RESET_SRC_CLK_LOSS  ) >> ( AON_PMCTL_RESETCTL_RESET_SRC_S ))
#define RSTSRC_SYSRESET               (( AON_PMCTL_RESETCTL_RESET_SRC_SYSRESET  ) >> ( AON_PMCTL_RESETCTL_RESET_SRC_S ))
#define RSTSRC_WARMRESET              (( AON_PMCTL_RESETCTL_RESET_SRC_WARMRESET ) >> ( AON_PMCTL_RESETCTL_RESET_SRC_S ))
#define RSTSRC_WAKEUP_FROM_SHUTDOWN  ((( AON_PMCTL_RESETCTL_RESET_SRC_M         ) >> ( AON_PMCTL_RESETCTL_RESET_SRC_S )) + 1 )
#define RSTSRC_WAKEUP_FROM_TCK_NOISE ((( AON_PMCTL_RESETCTL_RESET_SRC_M         ) >> ( AON_PMCTL_RESETCTL_RESET_SRC_S )) + 2 )
//@}

I hope this will help,

Regards,

Hi Clément,

Will the resetSource value be set to on the below?

RSTSRC_PWR_ON 
RSTSRC_PIN_RESET 
RSTSRC_VDDS_LOSS 
RSTSRC_VDDR_LOSS 

RSTSRC_CLK_LOSS 
RSTSRC_SYSRESET 
RSTSRC_WARMRESET 
RSTSRC_WAKEUP_FROM_SHUTDOWN 
RSTSRC_WAKEUP_FROM_TCK_NOISE

.

I am asking because I tried checking the "resetSource" variable with these values, but resetSource is not getting set at all.

.

Regards,

Saurav

Hi,

You are correct, the resetSource should take one of the values you have mentioned. 

Two elements:

- RSTSRC_PWR_ON has the value 0x00 so this could explain why the value does not seem to be set.

- Generally speaking, remember that BLE projects use a pretty aggressive level of optimization. Make sure the code does not get optimized/removed by the compiler. If this is the case, make sure to use volatile variables.

Regards,

Hi Clément,

There is an update on this disconnect issue.

We were able to put our board in debug mode and when we tried to reproduce the issue than it was seen that the exception is coming when the issue is reproduced. 

While debugging we were able to find that we are getting an exception when the issue was reproduced.

Below is the snapshot of code when the exception was found:

For the exception we have added some code (provided by TI only) in our workspace, below is the link of the changes:

https://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_5_10_00_02/docs/blestack/ble_user_guide/html/ble-stack-3.x-guide/debugging-index.html#using-ti-rtos-and-rov-to-parse-exceptions

Please find the below snapshot of some exceptions we are observing:

Every time the  exceptions are due to “Hard Fault: FORCED: BUS FAULT: PRECISERR.Data Access Error” but different Exception call stacks were observed.

Below is the snapshot of Fault:

We have tried to resolve the issue by updating the Program stack in “cc2640_r2_csdk.cfg” from 1024 to 2048 but the issue was not resolved.

We have also updated the “SBP_TASK_STACK_SIZE” in Simple_peripheral.c from 644 to 644*2, but still we are getting the same exception.

Because of this we are unable to do anything further and our SOP getting blocked.

Please support on urgent basis ASAP.

Regards,

Saurav

Hi Clément,

We have followed the steps you have mentioned.

Below are the snapshots of one of the exception found:

Below is the code snippet where the issue is found:

.

This code file is not changed by our project at all.

So, we are not able to know why the exception is coming in this code line.

.

.

Regards,

Saurav

Regards,

Saurav

Hi,

Not sure I can spot the issue given the small snippet provided. Could you please specify, the address of the variables hdr and tmp, their addresses?

Thanks,