CC2340R5: Connection Parameter Update Rejected by LL

Part Number: CC2340R5

Tool/software:

Hello TI Members,

What could be the possible reason for the link layer to reject connection parameters, even though they are valid and were previously accepted?

This issue occurs after the mobile device connects and pairs with the board, sets the MTU size to 244 bytes, and then updates the connection parameters.


The first log corresponds to BLEAPPUTIL_LINK_PARAM_UPDATE_EVENT from the SDK, while the second log corresponds to BLEAPPUTIL_LINK_PARAM_UPDATE_REJECT_EVENT.

Note that only 355 ms elapsed between the acceptance and rejection.

The printed variables are connTimeout, connInterval, and connLatency, which come from the raised event payload (gapLinkUpdateEvent_t).

Best regards,

Ahmed

  • Hi Ahmed,

    Thank you for reaching out.  Can you share what the value of status and opcode are in the gapLinkUpdateEvent_t payload? This may help us figure out what may be going on. Could you also specify which smart phone OS is being used?

    Best Regards,

    Jan

  • Hi Jan,

    Thank you for your quick response.

    I am facing the issue with multiple phones, including the iPhone 13 (iOS 17.6.1), iPhone 16 (iOS 18.1.1), S10 (Android 12), and S10e (Android 12). However, it occurs more frequently on the S10 and S10e.

    The following logs are from the S10, with op code = 24, status = 30

    Accepted:

    Rejected:

    This Shows the times that the same parameters were accepted and rejected 


    Sniffer Session:

    S10.pcapng

    Best
    Ahmed

  • Hi Ahmed,

    Got it. This is helpful. Can you share the SDK version you are using? If you are not on the latest (8.40), then could you attempt to test this on the latest? Is the behavior easy to reproduce or is a custom application required on the smart phone side to cause the behavior to occur?

    Best Regards,

    Jan

  • Hi Jan,

    I am currently using version 8_10_01_02. I will update to 8.40 and keep you posted. This behavior is easy to reproduce without any modifications; all I need to do is connect to the board using the 'nRF Connect' mobile application.

    Best regards,
    Ahmed

  • Hi Jan,

    I tested the latest SDK version (8.40) on an S10 mobile using the basic_ble example (added some logs and made minor changes for the connection parameters) but the issue still persists.

    S10_8_40.pcapng

    Best regards,
    Ahmed

  • Hi Ahmed,

    Got it. Thank you for testing on latest SDK, this makes it much easier for R&D to reproduce if needed. To clarify, does the issue occur if you use the default/unmodified connection parameters?

    Best Regards,

    Jan

  • Hi Jan,

    Yes, the attached connection parameter requests are handled internally by the mobile device without any input from me.

    As you can see, it initially sets the connection parameters to 6, 6, 0, 500, which are accepted every time until the service discovery is completed. Afterward, it automatically changes the parameters to 39, 39, 0, 500, which are sometimes accepted and sometimes rejected.

    I’ve attached the sniffer session without any filters in case you’d like to review it.

    S10_sniffer.pcapng

    Best regards,

    Ahmed

  • Hi Ahmed,

    Got it. Thank you! I would like to reproduce this on my side. Can you specify the exact steps you are doing in the app to cause the behavior to occur?

    Best Regards,

    Jan

  • Hi Jan,

    I am using the basic_ble example after doing the following modifications:

    1. Enabling "Peer Conn Param Update Reject Ind"

    2. Set "Parameter Updates Request Decision" to "Accept All"



    3. Add "BLEAPPUTIL_LINK_PARAM_UPDATE_REJECT_EVENT" event to eventMask in connectionConnHandler



    4. Add some logs in connectionConnHandler function in case of event = BLEAPPUTIL_LINK_PARAM_UPDATE_EVENT to observe the issue

    The board should start advertising by default after flashing the binary. I use the 'nRF Connect' application on my mobile to connect to the board. The issue may not occur on the first attempt, so you can disconnect and reconnect multiple times to reproduce it. However, in my case, it happens very frequently, so it doesn't take much time.

    Best Regards,

    Ahmed

  • Hi Ahmed,

    I made the modifications you had mentioned as well as increased the max PDU size to 255.

    I also added a debug print statement for when the link layer rejects the request, but i was unable to reproduce the behavior on my side. I have attached my project to this message (in the archive, there is also a pre-compiled image you can flash), can you test it on your side and see if you can reproduce the behavior using my project?

    7028.basic_ble_LP_EM_CC2340R5_freertos_ticlang.zip

    Best Regards,

    Jan

  • Hi Jan,

    I have tried the project you sent, and I was able to reproduce the issue. You can find the logs attached.

    S10_TI_Project_Sniffer.pcapng

    Best regards,

    Ahmed

  • Hi Ahmed,

    Got it. Thank you for confirming. Just wanted to make sure that I wasn't missing anything in the image. Could you specify the exact steps you are taking in the app as well as the connection parameter values used for each request?

    Best Regards,

    Jan

  • Hi Jan,

    There are no special steps I take to make the issue occur. I simply open the app, let it scan for the board, then press "Connect," and the issue happens.

    Regarding the connection parameters, I don’t configure anything manually—they are sent by the mobile device during and after the connection process.

    As you can see, the following connection parameters are sent by the mobile device before the service discovery, and they are always accepted:


    After this step, the mobile device tries to set the connection parameters to the following values, which are sometimes accepted and sometimes rejected:

    Best regards,
    Ahmed

  • Hi Ahmed,

    Understood.I follow the steps outlined below, but was unable to reproduce. Do you see an issue with the steps?

    1. Flash LP-EM-CC2340R5 with the project shared earlier

    2. Reset device a few times.

    3. Connect using nRF Connect

    4. Wait a few seconds

    5. Disconnect

    6. Wait a few seconds

    7. Repeat steps 3 through 6

    However, using a Pixel 9 Pro XL ( Android 15 ) or an iPad Pro 11-inch 4th Gen (iPadOS 18.1.1) I was unable to reproduce. For sanity testing, do you have access to an Android device that is on Android 15? If so, then could you retest?

    Best Regards,

    Jan

  • Hi Jan,

    The steps are correct. While I don’t have access to Android 15 devices, I retested the issue using other devices, and it didn’t occur. However, the problem appears to be more frequent on S10 and S10e devices, as I was able to consistently reproduce it on those models.

    If you don’t have access to these models and need specific logs, feel free to send me the binary, and I’ll test it for you.

    Best regards,
    Ahmed

  • Hi,

    Attached is the image. I used to attempt to reproduce. Can you try it on your end?

    basic_ble_LP_EM_CC2340R5_freertos_ticlang.out

    Given the behavior you are observing, its possible the issue was present on prior builds of Android, but was resolved in subsequent builds or by different Android manufacturers which is why you are unable to see it on newer phones.

    Best Regards,

    Jan

  • Hi Jan,

    I was able to reproduce the issue using the S10 phone with the binary you sent. You may be correct that it might be related to the phone manufacturer, but the issue was also observed on the iPhone 13 (iOS 17.6.1) and iPhone 16 (iOS 18.1.1) previously. However, it isn't common on iPhones; it is more frequent on the S10 and S10e phones.

    Feel free to send me any other binary you'd like me to test.

    Best regards,
    Ahmed

  • Hi Ahmed,

    Thank you for testing! Its likely this issue may have already been resolved on Android and could be open on Apple. Are you able to test with a newer Android device to confirm?

    Best Regards,

    Jan