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.

CC2650MODA: Frequent disconnects but only when paired

Part Number: CC2650MODA

Hey,

I have a few BLE sensor devices based on the CC2650MODA.
Since the sensor information might be considered personal, I've opted to apply a PIN-code based pairing process and did so by setting the permissions of the relevant characteristics to GATT_PERMIT_AUTHEN_READ / GATT_PERMIT_AUTHEN_WRITE.
I've noticed that ever since making this change, my devices are frequently disconnecting (at random intervals) from the central device.

The sensor application is running on a CC2650MODA with an application based on the SimpleBLEPeripheral from version 2.02.01.18.
The central is a Raspberry Pi 3 with its built-in Bluetooth, BlueZ 5.47 and running an application based on the Bluez D-Bus API.
When the application attempts to read/write a characteristic that requires authentication, Bluez automatically starts the pairing process (using a 6-digit PIN code) which seems to work as expected.
The devices are paired and reading/writing characteristics work as expected and notifications do as well but the connection drops from time-to-time.

I've recently tried to use an ESP32 as the central and it too behaves similarly. When pairing isn't needed the connection stays active for very long periods (weeks) but when pairing was applied connections drop after ~80 seconds.

Is there anything else I'm missing and need to change in my BLE application for the secured connection to remain alive?

Thanks in advance,
Assaf

  • Hello Assaf,

    You'll need to identify the disconnect reason to investigate further. I would start by taking a BLE air sniffer capture (not HCI dump). Make sure it captures the pairing sequence so that you get decrypted PDUs once pairing occurs.

    Best wishes
  • Hey JXS,

    The disconnect reason from the ESP32 is 0x22, mapped to "LMP Timeout".

    I've captured the BLE packets in the attached file. My environment seems to be very noisy, but you can see the connection request in packet 256. The peripheral device's MAC address is a0:e6:f8:d1:d1:07. I can see the connection starting as expected. My application will try to read a specific characteristic, and if that fails because pairing is needed, it will then try to pair. Assuming I read the dump correctly, that happens on packet number 379+380.
    I'm not exactly sure what happens then. Some keys are exchanged but I don't see any data flowing. The app should attempt to read the characteristic again after pairing was completed (which according to my logs, it does). I then waits for notifications on said characteristic. Those also work as expected. However, the connection still disconnects after ~80±10 seconds. This happens even though notifications still work until the end.

    My connection parameters are as follow:

    // Minimum connection interval (units of 1.25ms, 80=100ms) if automatic
    // parameter update request is enabled
    #define DEFAULT_DESIRED_MIN_CONN_INTERVAL     80
    
    // Maximum connection interval (units of 1.25ms, 200=250ms) if automatic
    // parameter update request is enabled
    #define DEFAULT_DESIRED_MAX_CONN_INTERVAL     200
    
    // Slave latency to use if automatic parameter update request is enabled
    #define DEFAULT_DESIRED_SLAVE_LATENCY         3
    
    // Supervision timeout value (units of 10ms, 1000=10s) if automatic parameter
    // update request is enabled
    #define DEFAULT_DESIRED_CONN_TIMEOUT          1000

    For what it's worth, the ESP32 BLE stack is based on Bluedroid (don't know which version).
    I've seen other forum topics blame DLE and buggy Android stack implementations. My stack configuration is the following:

    /* BLE Host Build Configurations */
    -DHOST_CONFIG=PERIPHERAL_CFG
    /* -DHOST_CONFIG=CENTRAL_CFG */
    /* -DHOST_CONFIG=OBSERVER_CFG */
    /* -DHOST_CONFIG=BROADCASTER_CFG */
    /* -DHOST_CONFIG=PERIPHERAL_CFG+OBSERVER_CFG */
    /* -DHOST_CONFIG=CENTRAL_CFG+BROADCASTER_CFG */
    /* -DHOST_CONFIG=PERIPHERAL_CFG+CENTRAL_CFG */
    /* -DHOST_CONFIG=OBSERVER_CFG+BROADCASTER_CFG */
    
    /* GATT Database being off chip */
    /* -DGATT_DB_OFF_CHIP */
    
    /* Include GAP Bond Manager */
    -DGAP_BOND_MGR
    
    /* BLE v4.1 Features */
    /* -DBLE_V41_FEATURES=L2CAP_COC_CFG+V41_CTRL_CFG */
    /* -DBLE_V41_FEATURES=L2CAP_COC_CFG */
    /* -DBLE_V41_FEATURES=V41_CTRL_CFG */
    
    /* BLE v4.2 Features */
    /* -DBLE_V42_FEATURES=SECURE_CONNS_CFG+PRIVACY_1_2_CFG+EXT_DATA_LEN_CFG */
    /* -DBLE_V42_FEATURES=SECURE_CONNS_CFG+PRIVACY_1_2_CFG */
    /* -DBLE_V42_FEATURES=PRIVACY_1_2_CFG+EXT_DATA_LEN_CFG */
    /* -DBLE_V42_FEATURES=SECURE_CONNS_CFG+EXT_DATA_LEN_CFG */
    /* -DBLE_V42_FEATURES=SECURE_CONNS_CFG */
    /* -DBLE_V42_FEATURES=PRIVACY_1_2_CFG */
    /* -DBLE_V42_FEATURES=EXT_DATA_LEN_CFG */
    
    /* Include Transport Layer (Full or PTM) */
    -DHCI_TL_NONE
    /* -DHCI_TL_PTM */
    /* -DHCI_TL_FULL */

    I don't think it's related to DLE, EXT_DATA_LEN_CFG isn't enabled.

    What might be the issue?

    Thanks in advance,
    Assaf

  • Forgot to attach the BLE dump...sniff.psd

  • Hey JXS,

    I've attached the relevant results, but I'm not sure what to make of them.
    Is there anything that stands out to you?

    Thanks again,
    Assaf

  • HelloAssaf,

    In regards to the sniff.psd, the log does not provide any insight to the issue other than the master stops transmitting leading to the supervision timeout (LSTO). I do not see any unhandled control procedures, however, the sniffer is not able to decode the encrypted portion of the connection. I would suggest investigating further on the master side to determine why it stops transmitting during the connection.

    Best wishes

  • Hey JXS,

    This was indeed a bug in the ESP32's BLE stack.

    Thanks,
    Assaf
  • Hello Assaf,

    Thank you for confirming and updating the ticket likewise.

    Best wishes