• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 55 subscribers
  • Views 3346 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.

Connection Parameter Update Request Issue

tylerw
Intellectual 555 points

Hi All,

The test setup consists of two 2540's running 1.1 Ble Stack.

I am observing an issue where the Slave appears to lose synchronization following a connection parameter update request.  This happens roughly 25% of the time, so it appears it could be timing related.  The other 75% of the time the connection parameter update works as expected.

The slave is setup with automatically request connection parameter update option enabled.  I can observe the correct connection parameter update transaction take place:

Slave: L2CAP Connection Parameter Update Request

Master: L2CAP Connection Parameter Update Response (Accepted)

Slave: Ack's the response

Master: LL_CONNECTION_UPDATE_REQUEST containing parameters suggested by slave

Slave: Ack's the LL_CONNECTION_UPDATE_REQUEST

Communication continues until the ConnInstant specified by the master in the LL_CONNECTION_UPDATE_REQUEST.  The slave does not communicate at the ConnInstant connection event and the slave is never heard from again. The master continues to Tx for every connection event (at ConnectionInterval_new) until the link eventually terminates due to link supervision timeout.

A couple questions:

1) Is there anyway to disable autonomous acceptance of the Connection Parameter Update Request at the Master? (Ie the request would go controller->host->application before a response is sent).

2) How can I go about debugging this further?  It appears to be a low-level issue in the controller, and I have no visibility at that level.

Thanks,

-Tyler

 

  • 0
    Intellectual 555 points

    TI folks, any comment on this?  

    I'm still experiencing the issue -  I have an FTS sniffer log I can share.  The only way to work around it is to delay all other data/control traffic until after the connection parameter update is complete.

    -Tyler

  • 0 in reply to tylerw
    TI__Guru 57865 points

    Hi Tyler,

    I have not experienced what you describe but if you provide a step by step procedure I might be able to reproduce it . Do you have a custom design or do you use one of our kits? 

    Can you test with the latest stack release (currently v1.2.1) to see if the issue is still present?

    Br

  • 0 in reply to J Lindh
    Intellectual 690 points

    Nick,

    I can confirm this behavior, I've seen this on 1.1, 1.2 and 1.2.1.  I reported it to Greg S back on version 1.1, and it was supposedly fixed, but I've still seen it on the later versions.

    John

  • 0 in reply to J Lindh
    Prodigy 250 points

    Hi Nick ,

    Can you please put some light on the link below 

    http://e2e.ti.com/support/low_power_rf/f/538/p/188188/676680.aspx#676680

    Thanks in advance ,

    Senthil

  • 0 in reply to J.Sample
    Intellectual 515 points

    I have the same issue with the standard unmodified heartrate minitor keyfob demo from 1.2.1

    I don't know how to easily update parameters via TI tools so I have used BlueGiga USB dongle and their frontend to update the slave parameters.

    Keyfob most of the time just dies.  The only way out is cold reset.

    http://e2e.ti.com/support/low_power_rf/f/538/t/188179.aspx

    Leo

  • 0 in reply to Leo Bodnar
    Intellectual 555 points

    I can also verify that I still see the issue on stack v1.2.1.  I have implemented a work-around to avoid data transfer until the connection parameter update is complete, but it adds a lot of time overhead to connection setup.

    Also, the issue adds the problem that you can't effectively update your data rate during a connection with active data transfer occurring.

    Has anyone had any luck debugging the issue further?

    -Tyler

  • 0 in reply to tylerw
    TI__Mastermind 34660 points

    Tyler, I have been attempting to replicate this issue and have not been able to.  I am establishing a connection and then sending the following update param requests from the slave:

    connection interval: 100, slave latency: 0, supervision timeout: 200
    connection interval: 200, slave latency: 0, supervision timeout: 300
    connection interval: 300, slave latency: 0, supervision timeout: 400
    connection interval: 400, slave latency: 0, supervision timeout: 500
    connection interval: 500, slave latency: 0, supervision timeout: 600
    connection interval: 500, slave latency: 1, supervision timeout: 700
    connection interval: 500, slave latency: 2, supervision timeout: 700
    connection interval: 500, slave latency: 4, supervision timeout: 700
    connection interval: 500, slave latency: 6, supervision timeout: 700

    These are all accepted by the master and I can see the connection events occurring in the packet sniffer capture.  I have tested this ten times and each time was successful.

    Can you provide some more detail about your setup?

    What hardware are you using? Are you using software from a sample project?  How are you calling the update param request?  Can you attach your sniffer capture?

    - Tim