• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 51 subscribers
  • Views 4531 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.

CC2541 Channel Map Request Causing Disconnects

Erick1
Intellectual 280 points
Other Parts Discussed in Thread: CC2541

The project is a peripheral GATT server and uses the 1.4.0 BLE stack. In a noisy environment, it seems that the central device is sending an LL_CHANNEL_MAP_REQ while connected with some channels marked as Not Used. I do not see these packets being sent by the BLE dongle using BTool and I do not get disconnects.

I noticed a note on the 1.3.1 version of the stack "Occasional slave connection failures would previously occur in cases in which the master device sends Update Channel Map requests while a large slave latency value is in use. This has been fixed." I was wondering if this is related. My connection parameters are: 25ms max and 25ms min, latency 0, timeout 5s.

The sequence of events appears to be the following based on a sniffer capture:

1. Repeated Empty PDU packets on the connection interval back and forth

2. Central sends LL_CHANNEL_MAP_REQ control packet.

3. CC2541 Peripheral sends Empty PDU packet

4. Central continues sending Empty PDU packets on the connection interval with no responses from the peripheral

5. Connection fails due to timeout

Any info would be greatly appreciated. Let me know if you require more details.

  • 0
    TI__Guru** 105180 points
    Hello Erick,

    Can you provide a BLE air sniffer trace of this behavior? Also, I do recommend using BLE 1.4.1.

    Best wishes
  • 0 in reply to JXS
    Intellectual 280 points

    Thanks. I will try to update to the 1.4.1. Here is a screen shot from the analyzer software I am using. I've reproduced the issue multiple times and the trace is always similar.

  • 0 in reply to Erick1
    TI__Guru** 105180 points
    Thank you for the screen shot. If possible, can you attach the full Frontline sniffer file (.cfa only)? There are other items we need to inspect that aren't reflected in the screen shot.

    Also, can you provide details on the Central device?

    Best wishes
  • 0 in reply to JXS
    Intellectual 280 points

    The central device uses an Azurewave aw-cu277 running the Searan stack.

    Here is another capture file that drops the connection in a similar manner except it looks like the channel map request is retried a few times. Thanks a lot for your help on this issue!

    capture_droppedConn2.cfa.zip

  • 0 in reply to Erick1
    Intellectual 280 points

    JXS,

    I noticed something interesting in the captures. On each failure, the slave gets the channel map request with a connInstant that is lower than the current event counter. Could this be causing an issue or should this be handled fine on the peripheral?

    Thanks,

    Erick

  • 0 in reply to Erick1
    TI__Guru** 105180 points

    Hi Erick,

    Absolutely.  Sending a Channel Map Update with an instant in the past (or not 6 events in the future) will cause a link drop. See BT4.0, Vol 6, Part B:

    5.1.2 Channel Map Update Procedure

    The Instant field of the LL_CHANNEL_MAP_REQ PDU shall be used to indicate the connEventCount when the channelMapNEW shall be applied; this is known as the instant. The master should allow a minimum of 6 connection events that the slave will be listening for before the instant occurs.

    When a slave receives an LL_CHANNEL_MAP_REQ where (Instant – connEventCount) modulo 65536 is greater than or equal to 32767 (because the instant is in the past), the Link Layer of the slave shall consider the connection to be lost and shall notify the Host.

    --

    It seems most of the connInstant values the master is using is 5 or less. Can this be changed on the master to use 6 as per the BT4.0 spec?

    Best wishes

  • 0 in reply to JXS
    Intellectual 280 points
    JXS,

    Thank you for your response! I was suspecting this was the case. I will look over this with the developer working on the central device. I will verify your answer as soon as I can test it. I appreciate your help with this!

    Thanks,
    Erick