This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DLE support from Android BLE 4.2 working but DLE Support from Windows BLE5.0 negotiation fails.

  android large mtu.pcapnghp pavilion ble 5.pcapng

After the MTU size exchange of 247 bytes with Android LL_LENGTH_REQ/LL_LENGTH_RSP are exchanged with 123 byte octets for TX and RX. Data flows properly after that.

But with Windows, after the MTU size exchange of 247 bytes an LL_LENGTH_REQ is sent with 251 byte octet. No LL_LENGTH_RSP is sent by Nordic from the nRF52832

and no further data exchange takes place.

Parents
  • HI Mark, 

    the slave is sending a ATT_EXCHANGE_MTU_REQ in the same connection event as the master sends the LL_FEATURE_REQ. Our nrf_ble_gatt.c module will initiate a  ATT MTU exchange, i.e. call sd_ble_gattc_exchange_mtu_request()  if the NRF_SDH_BLE_GATT_MAX_MTU_SIZE is larger than the BLE_GATT_ATT_MTU_DEFAULT. 

    So it would seem that the nRF is waiting for the ATT_EXCHANGE_MTU_RSP, while the central is waiting for the LL_LENGTH_RSP. I am not quite sure which request that should have priority, need to check the spec / confer with the SoftDevice team. 

    Meanwhile, could you try to set NRF_SDH_BLE_GATT_MAX_MTU_SIZE == BLE_GATT_ATT_MTU_DEFAULT and see if that resolves the "deadlock"? 

    Best regards

    Bjørn

  • Do you get the BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST event on the nRF side? Could you check whether the NRF device is calling sd_ble_gap_data_length_update() to respond to the LL_LENGTH_REQ as shown in the Data Length Update Procedure Message sequence chart.

  • Added a 500ms delay in on_connected_evt() just before the call to sd_ble_gattc_exchange_mtu_request(). It still did not work. I will be able to take an OTA trace in the morning and attach it.

  • Great. I'll wait for the OTA trace and then analyze it with the SoftDevice team to figure out what the cause of the issue is. 

  • 0743.hp pavilion large mtu 02-25-20.pcapng

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    0> REBOOT (9)
    0> Bluetooth Name NM04-000008
    0> Board Type D045
    0> Model Type ETM
    0> FPGA Ver Model 4 Version 4
    0> Firmware Ver 1.8.330
    0> Firmware Type FIELD_BLE_UART
    0> SoftDevice Ver 6.1.0
    0> BootLoader Ver 6 (INSTALLED)
    0> Mfg Data Ver 4
    0> Sys Config Ver 10
    0> API Versions OK
    0> Bluetooth Enabled
    0> UART Enabled
    0> Stimulation Enabled
    0> Acceleration Disabled (0)
    0> Force Error Disabled (0)
    0> Electrode Map Field 8 Contact
    0> Reboot Reason Watchdog Timeout (Bootloader)
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • Hi Mark, 

    thanks for the trace. I forgot to ask which S132 version are you using? Looking at the trace its pretty clear that the nRF is not replying to the LL_LENGTH_REQ. 

    Can you confirm that sd_ble_gap_data_length_update() returns NRF_SUCCESS when its called on the BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST event? I assume that you do not get the BLE_GAP_EVT_DATA_LENGTH_UPDATE event after calling sd_ble_gap_data_length_update()?

    I also noticed that things break when its the nRF that sends the MTU Exchange Request, but when the Intel device( Central) initiates the MTU Exchange, then things proceed as normal. 

    Comparing 0743.hp pavilion large mtu 02-25-20.pcapng with default mtu size.pcapng, I cant really see why the nRF does not respond to the LL_LENGTH_REQ in the   0743.hp pavilion large mtu 02-25-20.pcapng when it does this in the default mtu size.pcapn. The LL PDU order is exactly the same in both traces. 

    Is this behavior 100% consistent, i.e. if you leave set the ATT MTU size higher than the default value then the negotiation Data length or ATT MTU negotioation halts every time?

    Could you try to add an even longer delay in on_connected_evt() just before the call to sd_ble_gattc_exchange_mtu_request()? Like a full second or more? We want to see if the nRF replies to the LL_LENGTH_REQ then and if the Intel device then initiates the MTU Exchange procedure. 

  • The sd_ble_gap_data_length_update() was not being called because it was in the wrong place in the code. We still printed the fact that we received the BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST in the log. Now that we are calling sd_ble_gap_data_length_update() in response to the BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST the negotiations are working and we can make a connection and transfer our file over DFU. Thanks

Reply
  • The sd_ble_gap_data_length_update() was not being called because it was in the wrong place in the code. We still printed the fact that we received the BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST in the log. Now that we are calling sd_ble_gap_data_length_update() in response to the BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST the negotiations are working and we can make a connection and transfer our file over DFU. Thanks

Children
No Data