• State Resolved
  • Locked Locked
  • Replies 21 replies
  • Answers 4 answers
  • Subscribers 53 subscribers
  • Views 478 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2642R: Connection is terminated immediately while using RF Block mode

Mehul Dalal
Expert 2180 points
Part Number: CC2642R

Hi,

My simple peripheral example is based on SDK 5.10. I am also using RF Block mode as well. The connection request  is made from the BTool with connection interval of 30 ms and Supervision timeout of 2 seconds.

As soon the stack sends GAP_LINK_ESTABLISHED_EVENT in the application, the firmware is calling DMMPolicy_setBlockModeOn() to enable the RF Block mode to ON for almost 200-250 ms before disabling the RF Block mode.

I am seeing that the connection is resulted in termination in case the RF Block mode is ON for 200 ms. If I start using the RF Block after the 1st connection interval rather than enabling it after receiving GAP_LINK_ESTABLISHED_EVENT, the connection is successful.

Is there anything in the BLE stack which requires the 1st connection interval to have RF mode enabled (not RF Block mode)?

  • 0
    TI__Guru**** 217617 points

    Hi Mehul,

    I would like to further understand your application.  Have you used the DMM Integration SimpleLink Academy Lab to add DMM to your simple peripheral project, or have you import a DMM example which uses simple peripheral BLE functionality?  Are you actually using a second stack application that needs RF access or are you only using DMM Block Mode to disable BLE temporarily?  For either case, why is block mode required for your design?

    Regards,
    Ryan

  • 0
    TI__Mastermind 42250 points

    Hi Mehul,

    On top of answering the questions Ryan posted, could you verify if the behavior is still present if you delay the time before you set RF Block mode? After connection establishment, there may still be some BLE activity that needs to be completed. It is common for connection parameters to be updated rapidly after a connection has been established and that may be being interrupted here. I would suggest waiting a few connection events before turning on RF Block mode.

    Best Regards,

    Jan

  • 0 in reply to Ryan Brown1
    Expert 2180 points

    Hi Ryan,

    Yes, we had used SimpleLink Academy lab only to integrate the DMM. 

    We do not have a second stack. However, we required to use the DMM to design the application power management to conserve energy. Surat Baker is aware of that.

    We believe that the DMM is correctly integrated as the test results are matching up with the expectations.

    However, I was just wondering if the RF Block mode has any role to play when the connection is made.

  • 0 in reply to Jan
    Expert 2180 points

    Hi Jan,

    As mentioned, if I start enabling the RF Block mode for the BLE stack after the 1st connection interval, the connection just works fine. However, if the RF Block is enabled immediately after receiving GAP_LINK_ESTABLISHED_EVENT event from the stack, the connection results into termination.

    Do you know if the TI BLE stack or the BLE specification itself requires the 1st connection interval to happen without RF Block mode enabled as we have an observation that the connection just works fine if the RF Block mode is enabled after the 1st connection interval but does not work if enabled after GAP_LINK_ESTABLISHED_EVENT.

  • 0 in reply to Mehul Dalal
    TI__Guru**** 217617 points

    Thanks for providing the additional information I asked for.  I've provided links to the SimpleLink Current Consumption Measurement Application Report and Power Measurement section of the BLE5-Stack User's Guide.  I will allow the BLE experts to comment on application behavior and recommend other power optimization techniques.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Expert 2180 points

    Hi Ryan,

    Thanks for the links. The understanding remains same and the firmware is working as expected as well. 

    I just wanted to know the impact of the behavior of the RF Block mode in the connection which I believe that the BLE expert from TI will provide a comment on. So, I will wait then.

    Mehul

  • 0 in reply to Mehul Dalal
    TI__Mastermind 25810 points

    Hey Mehul,

    I think Jan hit the key points here. To clarify, if you are setting block mode on during a control procedure and you don't allow it to complete, it can certainly lead to a disconnection by the peer. After the connection is established, things like connection parameter updates, security exchanges, etc can all be triggered by the peer. If you turn block mode on, you essentially stop the device from being able to respond to its peer in a timely manner (the packets would get delayed and retried until block mode is turned off).

    Waiting until the first connection event to turn block mode on would be a good approach to avoiding such an issue as you've already discovered. If you expect critical data to be exchanged, perhaps you can wait even longer, however this depends entirely on your application. 

    Hope this clarifies things.

  • 0 in reply to Ammar N
    Expert 2180 points

    Hi Ammar,

    Thanks for the information. I am just wondering about the BLE stack and the BLE specification expectations from the time GAP_LINK_ESTABLISHED_EVENT is received in the application. If the connection parameters are having interval of 30 ms, slave latency 0 and supervision timeout at 2 seconds, I expect the termination for the connection should not happen before 2 seconds i.e. Supervision timeout. From the Ellisys sniffer, I can see that there is no further connection parameter updates/security exchanges (not supported by our application anyhow), tec.

  • 0 in reply to Mehul Dalal
    TI__Mastermind 25810 points

    Hey Mehul,

    Can you share the ellisys trace? If it shows the disconnection we can determine it's cause to see if we are correct.

  • 0 in reply to Ammar N
    Expert 2180 points

    I do not have the sniffer file itself but I have an image of the sniffer. See atatched.

  • 0 in reply to Mehul Dalal
    TI__Mastermind 25810 points

    Hey Mehul,

    Thanks for the screenshot, this clarifies things. From the log, it looks like the peripheral (rightfully so), does not show up to the first connection event. The first connection event is critical, I gather this from the specification.

    In v5.2, Vol 6, Part B, Section 4.5. Connection state, it states that the connection is created but not established until the peer receives the first packet. Further down, the spec states the first packet received by the peer determines the anchor point for all subsequent connection events. Slave latency is not to be used until the peer receives a packet from the master with the NESN bit set to 1.

    So, it seems in the beginning of a connection, attending the first connection event is critical to continue a connection appropriately.

  • 0 in reply to Ammar N
    Expert 2180 points

    Thanks Ammar.

    I now can understand the BLE specification requirements. Thanks a lot for explaining it.

  • 0 in reply to Ammar N
    Expert 2180 points

    Hi Ammar,

    Just one more question. If the BLE spec reference suggests such need, is it fair to expect that the BEL stack should be sending GAP_LINK_ESTABLISHED_EVENT  to the application only after the connection is established in true sense? I might be wrong here as I can see there might be counter argument that the application must be aware of what the connection parameters are received from the CONNECT_REQ at earliest. So, having some more clarification in this regard would be really great.

  • 0 in reply to Mehul Dalal
    TI__Mastermind 25810 points

    Hey Mehul,

    No worries! To clarify, GAP_LINK_ESTABLISHED_EVENT  is actually called to the application as soon as it receives a valid connection indication (i.e. before the first anchor point) and the stack accepts the request. This is the current implementation. I can see what you mean by only sending the established event after the first connection event. But your point is valid and is likely why things are implemented this way. It also likely gives the peer an opportunity to trigger a disconnect should the device not accept the incoming connection parameters.

  • 0 in reply to Ammar N
    Expert 2180 points

    Thanks Ammar.

    I have one more question (looks like they are not stopping :)).

    If the RF Block mode is enabled immediately after GAP_LINK_ESTABLISHED_EVENT, do you know when and how the BLE stack decides that the connection established is not longer completed? I did not see any spec reference in that regard. Is there any timeout for this? Or some counter related to connection interval to ensure the data is exchanged after GAP_LINK_ESTABLISHED_EVENT  within certain number of connection interval?

  • 0 in reply to Mehul Dalal
    TI__Mastermind 25810 points

    Hey Mehul,

    We're definitely in some new territory here with block mode, so I'll do my best to answer your questions.

    When block mode is on, the stack will attempt to send out connection events but these attempts will be rejected. At this point, the stack should handle the rejections and it should change its state back to a non connected state. I'm not too sure of the details, but I know there is a timeout based on a certain number of retries.

    Do you see a GAP_LINK_TERMINATE_EVENT get triggered? I think the stack should return such event to the application so that its aware of the state change as well.

  • 0 in reply to Ammar N
    Expert 2180 points

    Hi Ammar,

    It would be great if you can get some more clarification on number of retries to prove the observations I have.

    Yes, the GAP_LINK_TERMINATE_EVENT is sent to the application when this happens.

  • 0 in reply to Mehul Dalal
    TI__Mastermind 25810 points

    Hey Mehul,

    I ran some tests at the application level by turning block mode on as you have on one of our out of box examples. I consistently saw ~6 retries using different connection parameters. For example: with a ~200ms connection interval approximately 1.12 seconds elapsed before the stack sent the GAP_LINK_TERMINATE_EVENT to the application.

  • 0 in reply to Ammar N
    Expert 2180 points

    Great. Thanks Ammar for the confirmation. The observation matches up with the information provided above.

    Is this number of retries defined in the specification or something implemented in the BLE stack as part of exception handling?

  • 0 in reply to Mehul Dalal
    TI__Mastermind 25810 points

    Hey Mehul,

    This number is defined in the specification. See spec v5.2, Vol 6, Part B, Section 4.5.2 Supervision timeout. It states if "the connection supervision timer reaches 6 * connInterval before the connection is established...". It goes on to state the connection is then considered lost.

    In our code, we define this in ll_common.h, under the define LL_LINK_SETUP_TIMEOUT.

  • 0 in reply to Ammar N
    Expert 2180 points

    Thanks for the specific reference Ammar. It really helped and I appreciate all the clarification you have made so far in this topic.