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.

CC2340R5: Connection parameter update request issue

Part Number: CC2340R5
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Hi,

I have a ble peripheral device. I have established connection with nrf connect app in Android phone and I want to send ble notification to the central application.

In my sysconfig, under peripheral configuration, I have used default pass to app as connection update parameter request. Using this configuration, if I send notification to the central then after sometime, ble disconnection happens with GATT LMP TIMEOUT error.

If I change the setting to Accept All in sysconfig, everything is working properly. I am not able to understand what is exactly happening. Can you please explain how these parameters are working.

  • Greetings Satakshi,

    You have three possible choices for processing the parameter update requests as a peripheral device. You could choose to unconditionally accept all incoming parameter update requests (Accept All), or the opposite, which is to deny all incoming parameter update requests (Deny all). The third option is that the parameter update request is passed to the application. It then becomes the application's responsibility to process the incoming request, and based on that, decide whether to accept, or reject, the parameter update request.

    An example of how this is done can be seen in the app_connection.c file in the basic_ble example from the TI SDK. Inside the Connection_ConnEventHandler(), you can find a case BLEAPPUTIL_LINK_PARAM_UPDATE_REQ_EVENT. Here, you can see that, as an example, the connection latency for the incoming request is checked, and based on that, the parameter update response is generated.


    When you report that a GATT LMP TIMEOUT occurs, this is likely due to a response not being received by the device that sent the update request in sufficient time. Could you please elaborate on how you are handling incoming parameter update requests in your application? Additionally, could you also provide a sniffer log for the same to allow for more in-depth analysis on this topic?

    Best,
    Achyut Ray

  • Hi Achyut,

    Thanks for the explanation. Currently I am using nrf connect application as the client in oneplus android phone. I feel the android OS is written in such a way that the disconnection is happening. So I selected accept all and gave full control to the phone to decide on the connection parameters. With that its working.

    Currently, I do not have the sniffer setup handy but will try to share logs.

  • Greetings Satakshi,

    When you select "Accept All", it is the peripheral that unconditionally accepts the incoming parameter update request from the Central, in this case your phone. I can't seem to understand why the peripheral's handling of the parameter update requests is causing a timeout-led-disconnection. One of the possible reasons this could be happening is because the peripheral is not processing the incoming parameter update request in the application layer, and thus not sending a response, in time (or at all), to the central.

    To be able to assist you further, I would like to request the following information:

    • A description of your SW and what you are trying to achieve. Additionally, could you let me know whether you are using out-of-box TI example
    • The aforementioned logs by you. I am particularly interested in the updated connection parameters that the central is asking the peripheral to update to.

    Thank you,
    Best,
    Achyut Ray