• State TI Thinks Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 52 subscribers
  • Views 670 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC2640R2L: Connection Parameter Update and "LL Ping" Collision

Kevork Sepetci
Prodigy 10 points
Part Number: CC2640R2L
Other Parts Discussed in Thread: CC2640, CC2640R2F

Hello,

We have two devices where a CC2640R2 acts as a Central and an NXP QN9083 acts as a peripheral. When we try to change connection parameters from the central, sometimes it collides with an "LL Ping" transaction and the connection parameter update fails with an LL_REJECT_EXT_IND message from the master. See the sniffer screenshot below. Is this collision between link layer messages a known issue with the TI stack? The sniffer log is attached (Software link: fte.com/.../bpalowenergy.aspx).

Some Observations:

  • The master (CC2640) is rejecting it's own connection param update. It is the one who requested the update and the parameters in the LL_CONNECTION_PARAM_RSP exactly matches those in the LL_CONNECTION_PARAM_REQ.
  • The CC2640's LL_REJECT_EXT_IND message shows the error code "Invalid LMP Parameters" but none of the parameters in the LL_CONNECTION_PARAM_RSP message from the peripheral seem invalid. They match the ones sent by the CC2640.
  • The Central application retried with the exact same parameters 1 or 2 minutes later (not shown) and it worked when there was no LL_PING_RSP in between.
  • Note that LL_PING requests and responses are not just empty connection events, they are actual messages defined in Core Spec 5.2 Volume 6, Part B, section 4.6.5.

  • 0
    TI__Guru**** 168357 points

    Hi,

    Thank you for your inquiry. I notified a colleague and he will reply as soon as possible.

    Regards,

    Rafael

  • 0
    TI__Mastermind 30119 points

    Hello,

    I have a few questions that may help us get to the bottom of this more efficiently. Which SDK version are you using? You mentioned that the CC2640R2 is acting as a central, are you basing your project on the simple_central example project? Are you on the BLE or BLE5 stack? Is this issue being observed on custom hardware or on a CC2640R2 LaunchPad?

    Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 10 points

    Hi Jan,

    • It's based on custom hardware.
    • We're not basing the project on the simple_central example project. The CC2640 is on a custom USB dongle and we send HCI commands to it from a script running on a PC.

    I'm not sure about the SDK version, I'll find out from teammates and report back.

    -Kev

  • 0 in reply to Kevork Sepetci
    TI__Mastermind 30119 points

    Hi Kevork,

    Thank you for the additional information. Are you able to connect to a different peripheral device to verify if this issue occurs with all devices or just the NXP QN9083 device? Also to confirm, the device is the CC2640R2L? You mention the CC2640, so I want to confirm. Is there any update with regards to the SDK version?

    Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 10 points

    Hi Jan,

    We are using the CC2640R2F (not CC2640R2L like I had described originally, sorry about that) with the BLE 4.2 SDK version 2.30.00.28.

    We have not tested with other peripherals but the response packets from the NXP QN9083 device seem valid and expected given the LL_PING_REQ and LL_CONNECTION_PARAM_REQ packets sent by the CC2640. The CC2640 rejected connection parameter update it had requested itself.

    Thanks,

    Kev

  • 0 in reply to Kevork Sepetci
    TI__Mastermind 30119 points

    Hi Kev,

    Would it be possible to test if this behavior occurs on the CC2640R2 5.10 SDK? The 2.30 SDK was released quite sometime ago and across all of the releases since many bugs and issues have been resolved. It is possible that this behavior was rectified in one of those releases. The following guide showcases what steps need to be taken to port a project from an older SDK to a new SDK.

    Migration Guides

    Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 10 points

    Hi Jan,

    This might take a while for us since the hardware is not designed by our team. In addition, our regulatory process requires us to do formal testing/validation on our third-party tools before we can use them for our present purpose, so updating firmware would require us to repeat a lot of testing. In any case we can try a newer version and report back.

    In the meantime, is it possible to see by analysis what the new TI firmware will do when, while it's waiting for an LL_PING_RSP packet, it receives an HCI command to update the connection parameters request? With our current TI firmware it has sent LL_PING_REQ with sequence number 0, and when the application requests a connection parameter update it immediately sends a LL_CONNECTION_PARAM_REQ with sequence number 1, without waiting for the LL_PING_RSP. I'm not sure if two different LL packets can be sent in a row as such. The peripheral then sends LL_PING_RSP followed by LL_CONNECTION_PARAM_REQ both with NESN=1 and a sequence number of 0.

    If the newest TI firmware handles it the same way, then upgrading won't fix our problem, and our team would need to troubleshoot differently.

    Thanks in advance,

    Kev

  • 0 in reply to Kevork Sepetci
    TI__Mastermind 30119 points

    Hi Kev,

    We have reason to believe that this issue may have been fixed in subsequent SDK releases. By looking at the release notes for the 3.10 SDK we see that issue BLESTACK-4571 (LLCP collisions after encryption start request leads to termination due to MIC failure) is resolved. I believe that this issue corresponds to the issue you are seeing. I would recommend porting to the latest SDK as a test to verify if this issue is not present. If porting to the latest SDK is not possible, then I would suggest porting to at least the 3.10 or 3.20 release.

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 10 points

    Hello. Thanks for the feedback.

    We tried this with SDK version 5.10 and observed the same results. The newer sniffer log is attached again.

    Sniffer Log with SDK 5.10.zip

    Basically, the TI SDK (Central) is sending 2 requests consecutively (LL_PING_REQ and LL_CONNECTION_PARAM_REQ) before receiving the response to the first one (LL_PING_RSP). Naturally, the peripheral tries to respond by sending the two responses consecutively (LL_PING_RSP and LL_CONNECTION_PARAM_RSP) but the TI SDK rejects the 2nd one (LL_CONNECTION_PARAM_RSP). I think the SDK is just getting confused about receiving the two consecutive responses even though it sent two consecutive requests. Maybe it is trying to parse the LL_PING_RSP response as if it were a LL_CONNECTION_PARAM_RSP or vice versa. This would explain the error code of "Invalid LMP Param" (0x1E) which is sent by the SDK.

    Also, I checked the Sequence Number (SN) and Next Expected Sequence Number (NESN) fields of all the packets between packet 9309 and 9574, including empty connection maintenance packets, and didn't see issues.  The TI SDK correctly increments the SN field when it sends two consecutive requests (i.e. it doesn't use the same SN for a different packet). The peripheral also correctly increments the SN field on it's side when sending two consecutive responses.

    I would be happy to meet over zoom or some other tool to share the analysis I've done so far on sniffer logs.

  • 0 in reply to Kevork Sepetci
    TI__Mastermind 30119 points

    Hi Kev,

    Thank you for verifying if the issue was present in the latest SDK. This is very helpful. I will consult with the team in order to get to the bottom of this. Expect an update in a few days. In the meantime, if you come across any new information, then please make a reply with the new info. Any new piece of data could be helpful in solving this more efficiently.

    Best Regards,

    Jan

  • 0 in reply to Jan
    TI__Mastermind 30119 points

    Hi Kev,

    I have communicated this behavior to the dev team and documented all of the described behavior in an internal ticket. They will look into this as soon as they are able to. I have provided them with all of the info you have provided (including the sniffer log) which will be extremely helpful. If you find any additional information, then let me know and I will get it to the dev team ASAP.

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 10 points

    Hi Jan,

    thanks for the help. We don't have any additional info but I will report back if we do. Let us know if there are updates.

    Thanks,

    Kev

  • 0 in reply to Kevork Sepetci
    TI__Mastermind 30119 points

    Hi Kev,

    R&D is still looking into this and the issue will be addressed. I truly apologize for the extended delay. I will update you as soon as I hear back.

    Best Regards,

    Jan