CC2541: Issues with connection stability

Hello Ilya,

Is it possible that a flash compaction in SNV is occurring during bonding? The CC2541 will likely drop the connection due to CPU and flash erase/write execution times on this device not allowing it to meet connection timing requirements (published limitation in the release notes). I suggest applying the findItem() OSAL SNV optimization that is provided in the pinned "CC254x with Android 6.x Marshmallow & 7.x [Updated Oct 2016] " post at the top of the BLE forum. This will reduce lookup times in the SNV.

Best wishes

The customer has tried proposed fix, but it didn't help.
During the experiment they identified that similar behaviour is shown when they try to ue Whit List functionality (connection errors happen in both cases - with and without WhiteList usage, but with WhiteList it happens much more often - they have 3 devices in the list)
When the customer tries to use sniffer, they can normally save the log for the connection when everithing runs well (see attaced log cc2541_connect_ok.psd. If there are connection errors, the sniffer hangs-up after central device sends connection request (cc2541_connect_error.psd) and after reset situation repeats. Peripheral device address is 0xE4D5149923B3.
So there are two questions now
- How to setup the sniffer so it can trace all the traffic?
- How to correctly use White List functionality (below is the procedure the customer uses)?
1. CC2541 HW reset.
2. With GAP_SETPARAMETER (0xFE30) time frames are set for the device (scan window, connection intervals, etc)
3. With HCI_LEADDDEVICETOWHITELIST (0x2011) they write peripheral devices adresses which are allowed to connect (if there is a device with random address, then thus step is skipped)
4. With GAP_DEVICEINIT (0xFE00) they initialize BLE.
5. With GAP_DEVICEDISCOVERYREQUEST (0xFE04) they start to discover peripheral devices.

Another question - are there any recommendations on scan window, connection intervals, etc, so central device can be more tolerant to some timing mismatches with peripheral devices?

Best regards,
Ilya

Hello Ilya,

It's not clear why the whitelist would impact connection stability since the whitelist is only used to filter devices prior to establishing a connection. Regarding the problem from the OP, was it determined that a flash compaction was occurring coincident to the failure?

What are the connection intervals being used? Can you run the test with power saving disabled (xPOWER_SAVING) to rule out the 32k clock as a contributing factor? I suggest not using the whitelist and troubleshooting the problem as it was originally reported.

I'm not sure what "tolerant to some timing mismatches with peripheral devices" means here in relation to scan parameters. The peripheral should comply with the Bluetooth specification w.r.t the air interface timing. Scan parameters only determine when the central / scanner is actively or passively scanning for advertisers.

Do you have access to an Ellisys or Frontline sniffer, or similar sniffer that can do precise timing analysis? This would be helpful here.

Also, it doesn't look like there were any sniffer files attached to your post. Please use the rich formatting to attach files.

Best wishes

cc254x_connect_error.psd

Jeff,

When they use white list they also experience troubles similar to what they observed earlier, but they happen more frequently - i.e. device cannot establish the connection and it breaks with similar symptoms.

 For the proposed fix regarding potential flash compaction issue - with this fix the behaviour didn't change, i.e. they still experience issues with connection.

I've attached sniffer logs to the thread.

BR,

Ilya

cc254x_connect_ok.psd 

Some additional information:
1. Connection parameters:
#define BLE_HI_CONN_INTERVAL_MIN 16 // 20 ms (n * 1.25 mSec)
#define BLE_HI_CONN_INTERVAL_MAX 16 // 20 ms (n * 1.25 mSec)
#define BLE_HI_SLAVE_LATENCY 0 //
#define BLE_HI_CONN_TIMEOUT 101 // 1 s supervision timeout

2. When the customer turns off xPOWER_SAVING, connection establishes in 100% cases, but then breaks after about 1 second (with white list).

Best regards,
Ilya

Hi Ilya,

I want go back to your first post. Do they see the connection drop if only one device is connected?
Also do they see the connection drop if the scanning is not happening, what are the scan interval and scan window and scan duration?

Can they change the timeout to 10s to see if they see the disconnection:
#define BLE_HI_CONN_TIMEOUT 1001 // 10 s supervision timeout

Best wishes

Zahid,
With xPOWER_SAVING turned off and supervision timeout 10s looks like connection is much more stable (at least for about 10 minute test).
So the question is how to get stable connection with power saving mode ON.
Please advise.

Ilya

Hi Ilya,

Is there any way they can test with a 32k crystal instead of the external clock signal?

Can they also try to divide the clock down to 200 - 400 mV amplitude?

I assume the clock is connected as described in the application note, right? www.ti.com/.../swra409a.pdf

Regards,
Fredrik

Fredrik, Zahid,
Could you please advise what are the recommended timing parameters for scan window, supervision timeout, etc for CC2541 at connection establish time and in connected state.
What confuses the customer - why we recommended 10 seconds and not 2 or 5? why it makes connection more stable?
Is it critical only at connection time and than after connection is established they can change supervision timeout to make it shorter?

Best regards,
Ilya

Hi,

There is no specific recommended parameters, but it is recommended to space out the different BLE procedures to avoid collision.
This is based on the application(number of connections, scanning, and advertising procedures). The parameters for some of these procedures(same used in CC254x as well) are described here: dev.ti.com/.../

10s was just a conservative number, increasing the timeout makes the connection more reliable when the probability of missing packets increases(especially when multiple procedures are simultaneously scheduled and during external radio interference).

Yes the timeout and intervals can be changed after the connection is established. You can use longer timeout and connection intervals during the connection, then change it after connection and pairing has finished.

Best wishes