This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2541 disconnects immediately after connection

Other Parts Discussed in Thread: CC2541

Hi,

We are using CC2541 as a peripheral. Currently, we are facing very strange issue, in which our peripheral device got disconnect from the central device immediately after connection. Following are the BLE Device Monitor logs:

15:47:24.571 > Connect request
15:47:24.782 > Gap Link Established: h=0 ci=16 lat=0 to=10
15:47:24.783 > XYZ connected
15:47:24.788 > Service discovery started
15:47:24.903 > ReadByGrpTypeRsp: status=20 n=0
15:47:24.908 > GAP Link Terminated: status=0 h=0 reason=0x08
15:47:24.909 > XYZ disconnected

The above mentioned issue happens with normally working device i.e. initially, the device was working fine and suddenly it reaches to the state where it disconnects immediately after connection. This issue goes away after resetting the device.

Please note, in "GAPROLE_CONNECTED" case of Peripheral State Notification callback function, we are checking for connection interval requested by the central device after making connection using "GAPRole_GetParameter( GAPROLE_CONN_INTERVAL, &connInterval);". If the requested connection interval is higher than 40ms then we are resetting connection interval using GAPRole_SendUpdateParam() to 20ms. 

As per the above logs it doesn't seem that update parameter goes to the central device as the connection interval was within expected range i.e. less than 40ms. But still does anyone think that above implementation may cause this issue?

Has anyone face this issue?

Appreciate your quick reply.

Thanks,

Dhaval

  • Hi Dhaval,

    Do you have a sniffer log that you can share? The error code suggests a connection timeout. Also, I suggest using CC Debugger on the peripheral to see if there are any errors.

    Best wishes
  • Hello Dhaval. Can you take a sniffer capture of this? I think this would clearly show the issue. Also, does the link terminate if you don't perform the ReadByGrpTypeReq or anything else so that only empty packets are being exchanged?

    FYI the 0x08 status means a supervision timeout occurred (LL_SUPERVISION_TIMEOUT_TERM). What are parameters the connection is being formed at (slave latency, supervision timeout, and connection parameter)? It's possible your supervision timeout is very tight and that one missed connection event (due to RF interference) would cause a supervision timeout.
  • Hi Tim/JXS,

    Thanks for your quick response!

    Following connection parameters I am using:

    Min. connection interval = 20ms

    Max. connection interval = 20ms

    Supervision Timeout = 10 seconds

    Slave Latency = 0

    Update parameter request enabled = TRUE

    Connection pause peripheral = 6 seconds

    And as I mentioned in my previous post, also on connection we are checking for a current connection interval. That we are getting using "GAPRole_GetParameter( GAPROLE_CONN_INTERVAL, &connInterval );", and if this value is higher than 40ms then we are resetting the connection interval to 20ms using "GAPRole_SendUpdateParam" function.

    Also I have captured packet sniffer logs, while this issue happens. Please find it attached herewith.

    Looking forward to your quick reply!

    Thanks,

    Dhaval

    Immediate Disconnection_Packet Sniffer.psd

  • Hello Dhaval. Is this on custom hardware or on a TI platform?
  • Hi Tim,

    Yes, we are facing this issue on Custom Hardware. And we are using TI BLE Stack v1.4.0.

    Let me know if you need any other information. BTW did you get anything from the BLE Sniffer Logs? You can see that Master was retrying continuously for Empty PDU. And finally got disconnected after Supervision Timeout. What is the reason? Why slave was not responding to the Master?

    Thanks,

    Dhaval

  • The sniffer logs indicate that there is a timing issue, likely caused by something that is incorrect on your custom hardware. You can attempt to verify this by:

    - attempting to run the software on a TI reference platform

    - run without POWER_SAVINGS defined

  • Hi Tim,

    I am facing exactly same issue which Dhaval was facing with CC2541 device connecting with AOS 7.0 while same device(slave) firmware is working fine with lower version of AOS. One different thing I'm noticing on immediate disconnection behavior is that, AOS 7.0 is sending GAP_LINK_PARAM_UPDATE request and immediately connection is getting terminated from peripheral device and starting to advertise again. When peripheral is keeping connection reliable with mobile phone(lower AOS than 7.0), peripheral is not seeing GAP_LINK_PARAM_UPDATE request.

    So is there a way to fix this from peripheral side?

    Thanks!