CC2541 stops connecting to mobile application

Dhaval V

Other Parts Discussed in Thread: CC2541, CC2540

Hi,

We have observed very weird issue, where our device stops connection with mobile applications, Android as well as iOS, after connect/disconnect the same device for around 1000+ time. I don't know what is wrong with the device.

Does the BLE stack stores some related information in NV memory? Any idea why this is happening?

Appreciate your quick reply.

Thanks,

Dhaval

over 9 years ago

0 Tim C over 9 years ago

TI__Mastermind 34660 points

Hello. No, there is nothing in NV that would be causing this.

What stack are you using?

When this occurs, is the CC2541 advertising?

Can you recompile without POWER_SAVINGS defined to see if it still occurs?

0 Dhaval V over 9 years ago in reply to Tim C

Genius 4470 points

Hi Tim,

Thanks for your prompt reply!

Yes, CC2541 is advertising and I am able to connect the device with BLE Device Monitor. But it is not connecting with Mobile Application, which was working fine before this issue came.

I am using BLE Stack v1.4.0.

As I said, this issue occurs after around 1000+ connect/disconnect cycle, it is difficult to reproduce. Though I will try to reproduce the issue without POWER_SAVINGS defined.

Also we have tried following things -

1. Soft reset the device, by calling "HAL_SYSTEM_RESET()" this function.
2. Verify the connection interval, which was set to 30ms for iPhone application.
3. Do OAD on the device.

Issue still persist after above mentioned experiments. This issue occurs with both Image A as well as Image B.

But, when we reflash the same firmware on the device, issue goes away!!! And that is why it seems that there is something in NV Memory, which causes this issue.

Thanks,
Dhaval

0 Tim C over 9 years ago in reply to Dhaval V

TI__Mastermind 34660 points

The fact that the device is advertising and you can successfully connect from Device Monitor makes me think something is off in the phone software. Can you somehow verify that the phone is scanning at this time and sending connection requests?

0 Dhaval V over 9 years ago in reply to Tim C

Genius 4470 points

Hi Tim,

We observe in BLE Packet Sniffer, which shows that slave is not responding to master's query and after some time master timed out. Also, as I said before after reflashing the same firmware using SmartRF Flash Programmer, everything works fine without changing anything on iPhone/Android Phone.

Thanks,

Dhaval

0 Tim C over 9 years ago in reply to Dhaval V

TI__Mastermind 34660 points

How do you know that the master is querying the device. That is, how do you know that the master is scanning?

It doesn't really make sense that the CC2541 would respond to scan / connection requests from one device (BTool) and not other devices. If that actually is happening, it would be due to an application software configuration. Are you using whitelists?

0 Dhaval V over 9 years ago in reply to Tim C

Genius 4470 points

Hi Tim,

As I said before, we have observed that in BLE Sniffer logs that Application was sending scan request to the peripheral device and our peripheral device was responding with Scan Response. Then device exchanging some data after that slave device stops responding to the master request. Thus master keeps retrying for some time and then disconnect.

No, I am not using Whitelists.

Thanks,

Dhaval

0 Tim C over 9 years ago in reply to Dhaval V

TI__Mastermind 34660 points

Can you post a sniffer log of this?

0 Dhaval V over 9 years ago in reply to Tim C

Genius 4470 points

Hi Tim,

Please find attached the sniffer logs. I have captured this logs when I was trying to connect to the device using iPhone application.

Thanks,

Dhaval

iPhone_Application_Device_Disconnects.psd

0 Tim C over 9 years ago in reply to Dhaval V

TI__Mastermind 34660 points

OK so the scenario we are discussing is clear now: the devices are in a connection, not advertising / scanning. Anyway, it appears the CC2540 stops responding after the first connection event.

Something like this usually points to a custom hardware / crystal timing issue. However, this doesn't entirely match up as you say it doesn't happen when connecting to Device Monitor. Are you using custom hardware or is this a TI EM? If it is custom, have you tried replicating without POWER_SAVINGS defined? If you can replicate without POWER_SAVINGS, this would likely rule out a custom hardware timing issue.

It would also be good to see the following sniffer captures to compare to this failing case:
- successful connection with mobile device
- successful connection with Device Monitor when the fail case has happened.
- successful connection with Device Monitor in non-fail case scenario.

0 Dhaval V over 9 years ago in reply to Tim C

Genius 4470 points

Hi Tim,

Thanks for your quick reply!

Actually I am not doubting hardware here, as the BLE module, including crystal, that we are using is CE/FCC certified. And our design was also reviewed by TI. Also, the same hardware is working with Device Monitor and also with Android Application on Stock Android phone like Moto E!

Apart from that, as I said before it will be little difficult to reproduce the issue again with POWER_SAVINGS disabled, as it comes after 1000+ Connect->Get Data->Disconnect cycles.

I have attached the sniffer logs for Device Monitor working case and iPhone application working case. There is nothing like failed case with Device Monitor as it is always working.

Let me know if you need any other information.

Thanks,

Dhaval

iOS_Multitool_Application_Working.psd

BLE_DM_Working.psd

0 Dhaval V over 9 years ago in reply to Dhaval V

Genius 4470 points

Hi Tim,

Did you get a chance to look at the sniffer log I have attached in my previous reply?

Thanks,

Dhaval

0 Dhaval V over 9 years ago in reply to Dhaval V

Genius 4470 points

Hi,

This is really a critical issue. Can someone please help me here?

Thanks,

Dhaval

0 Tim C over 9 years ago in reply to Dhaval V

TI__Mastermind 34660 points

There doesn't appear to be a difference between the working and failing connection sequences in the sniffer captures.

Are you writing to NV? I would try reading out the flash before the failure occurs and comparing it to the flash after the failure occurs. You can do this using Flash Programmer: www.ti.com/.../flash-programmer

I'm still not convinced that we can rule out hardware issues and would like to see if this replicates without POWER_SAVINGS.

0 Dhaval V over 9 years ago in reply to Tim C

Genius 4470 points

Hi Tim,

Thanks for your reply and sorry for my delayed response!

Yes, we are doing some NV operation, but that is not continuous. We are doing that only once after reset of the device.

Your suggestion is good to read back the flash of the faulty device and then compare it with the one it is programmed with. But that is not possible, as the debug interface is locked.

I am trying to reproduce this issue with POWER_SAVING disabled and will update your with the result. I observed very weird behavior, the device was continuously resetting if the watchdog timer is enabled and POWER_SAVING is disabled. So is it necessary to disable Watchdog timer when POWER_SAVING mode is disabled?

By the time the test completes, can you please let me know NV IDs that BLE stack is using? So that we can try to erase only that NV memory from our application and check whether issue is still persist or not.

Thanks,

Dhaval

0 Tim C over 9 years ago in reply to Dhaval V

TI__Mastermind 34660 points

Hello. No, you do not need to disable the watchdog timer when POWER_SAVING is disabled. Are you using the watchdog timer in your application normally?

The BLE NV ID's can be found in bcomdef.h:

/** @defgroup BLE_NV_IDS BLE Non-volatile IDs
 * @{
 */
// Device NV Items -    Range 0 - 0x1F
#define BLE_NVID_IRK                    0x02  //!< The Device's IRK
#define BLE_NVID_CSRK                   0x03  //!< The Device's CSRK
#define BLE_NVID_SIGNCOUNTER            0x04  //!< The Device's Sign Counter

// Bonding NV Items -   Range  0x20 - 0x5F    - This allows for 10 bondings
#define BLE_NVID_GAP_BOND_START         0x20  //!< Start of the GAP Bond Manager's NV IDs
#define BLE_NVID_GAP_BOND_END           0x5f  //!< End of the GAP Bond Manager's NV IDs Range

// GATT Configuration NV Items - Range  0x70 - 0x79 - This must match the number of Bonding entries
#define BLE_NVID_GATT_CFG_START         0x70  //!< Start of the GATT Configuration NV IDs
#define BLE_NVID_GATT_CFG_END           0x79  //!< End of the GATT Configuration NV IDs
/** @} End BLE_NV_IDS */

I would also recommend unlocking the debug interface and performing the test so that you can compare flash since this is a vital data point.

0 Dhaval V over 9 years ago in reply to Tim C

Genius 4470 points

Hi Tim,

I am initializing watchdog timer as follows:

WDCTL = 0x08;
WDCTL &= 0xFC;

I hope, I am using it correctly!

Also, can you please let me know the size/length for each of the above mentioned NV IDs memory. So that I can erase them and check whether it is solving the problem or not.

Thanks,

Dhaval

0 Dhaval V over 9 years ago in reply to Dhaval V

Genius 4470 points

Hi Tim,

As mentioned in my previous post, please let me know size/length for each of NV IDs used by TI BLE Stack.

Also correct me if I am using watchdog incorrectly.

Thanks,

Dhaval

0 Tim C over 9 years ago in reply to Dhaval V

TI__Mastermind 34660 points

Hello. That appears correct. You are setting it to watchdog mode, then setting the timer interval to ~ 1 sec. Are you kicking the watchdog correctly? Note that there are macros to control the watch dog in hal_mcu.h. If you remove the watchdog code, are you still seeing resets?

I don't think its a good idea to erase this information but here are the NV ID lengths. Note that you can find these by searching throughout the code for the NVID to see when it is written with osal_nv_write

The possible ID's are:

local IRK : 16 = (KEYLEN)
local CSRK : 16 = (KEYLEN)
local SIGN Counter : 4 = (sizeof( uint32 ))

also, each bond record will have
main gap bond record: 14 = (sizeof ( gapBondRec_t ))
gatt ccfg ID : 12 = sizeof ( charCfg )
local LTK : 27 sizeof(sizeof ( gapBondLTK_t ))
device LTK: 27 sizeof(sizeof ( gapBondLTK_t ))
device IRK: 16 (KEYLEN)
device CSRK: 16 (KEYLEN)
device sign counter: 4 (sizeof(uint32))

0 Dhaval V over 9 years ago in reply to Tim C

Genius 4470 points

Hi Tim,

Thanks for your reply.

I have got a very weird observation. I have tried to erase the NV memory location for the IDs used by the TI BLE Stack. And after erasing the main GAP bond record - "osal_snv_write( mainRecordNvID(idx), sizeof ( gapBondRec_t ), &bondRec );", the faulty device starts working normally. I mean the device starts connecting with the CynogenMod android phone, with which it was not connecting previously.

Please note, as I said before we are not using Pairing and thus there should not be anything in the bonding NV memory. But I think BLE stack is writing something at these locations and that stops device to make connection with CynogenMod android phones and sometimes also with iPhone!

Please help us to resolve this.

Thanks,

Dhaval

0 Dhaval V over 9 years ago in reply to Dhaval V

Genius 4470 points

Hi Tim,

Did you get a chance to look at this issue?

Awaiting your reply.

Thanks,

Dhaval

0 Tim C over 9 years ago in reply to Dhaval V

TI__Mastermind 34660 points

Hello. I can not think of any reason why the stack would do this besides if pairing occurs. If you think this is happening, you should be able to debug this by setting a breakpoint in osal_nv_write(). You could see where the write is originating by looking at the call stack.

Also, I still think it is a good idea to unlock the debug interface so you can compare flash before and after the issue occurs.

Bluetooth®︎

Bluetooth forum

CC2541 stops connecting to mobile application