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

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

Mark P. Mendelsohn — Wed, 26 Feb 2020 22:56:49 GMT

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

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

bjorn-spockeli — Wed, 26 Feb 2020 08:17:09 GMT

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.

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

Mark P. Mendelsohn — Tue, 25 Feb 2020 17:16:38 GMT

devzone.nordicsemi.com/.../0743.hp-pavilion-large-mtu-02_2D00_25_2D00_20.pcapng devzone.nordicsemi.com/.../8322.large-mtu-hp-pavilion-2_2D00_25_2D00_20-v2.log

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

bjorn-spockeli — Tue, 25 Feb 2020 08:36:12 GMT

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.

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

Mark P. Mendelsohn — Tue, 25 Feb 2020 00:23:18 GMT

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.

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

bjorn-spockeli — Fri, 21 Feb 2020 08:50:33 GMT

OK, that is interesting. I see that the MTU exchange procedure now occurs after all the LL transactions and is triggered by the master , instead of immediatly after the connection establishment triggered by the slave as before. So it could be that the time and place of the MTU exchange has a role to play here.

Did you try leaving the MTU size at 247 on the Nordic side and then just delay the sd_ble_gattc_exchange_mtu_request() call that triggers the BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST from the slave? In my previous reply I stated that a delay should be added before the on_exchange_mtu_request_evt() call in nrf_ble_gatt_on_ble_evt(). THis is incorrect, it should have been the on_connected_evt() call under the BLE_GAP_EVT_CONNECTED case in nrf_ble_gatt_on_ble_evt() in nrf_ble_gatt.c

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

Mark P. Mendelsohn — Thu, 20 Feb 2020 21:34:33 GMT

devzone.nordicsemi.com/.../default-mtu-size.pcapng devzone.nordicsemi.com/.../default-mtu-size.log

When the default MTU size is used on the Nordic side, the negotiations are successful.

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

bjorn-spockeli — Thu, 20 Feb 2020 19:23:05 GMT

According to the RTT logs from the nRF the connection is disconnected with reason 0x13( BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION), i.e. the central tore down the connection. This is not shown in the on-air trace, as both slave and master keeps sending empty PDU after the LL_LENGTH_REQ. Did you stop the capture before the disconnection occured?

I assume that sd_ble_gap_data_length_update() returns NRF_SUCESS? The actual LL_LENGTH_RSP is sent asynch from the sd_ble_gap_data_length_update() call and you will get the BLE_GAP_EVT_DATA_LENGTH_UPDATE event when the response has been sent. Do you recieve this event? If the link is disconnected before this occurs, then that explains the missing BLE_GAP_EVT_DATA_LENGTH_UPDATE event and the missing LL_LENGTH_RSP, but the fact that the on-air trace indicates that the link is still active puzzles me.

Just to check if the ATT_EXCHANGE_MTU_REQ is casing the issues, could you try to add short delay before the on_exchange_mtu_request_evt call under the BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST case in nrf_ble_gatt_on_ble_evt() in nrf_ble_gatt.c?

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

Mark P. Mendelsohn — Thu, 20 Feb 2020 17:48:06 GMT

devzone.nordicsemi.com/.../largemtu-hp-pavilion.log devzone.nordicsemi.com/.../hp-pavilion-ble-5-02_2D00_20_2D00_20.pcapng

Attached is a new set of traces from both OTA and RTT sides.

We are getting the BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST. There was no

initial reply with sd_ble_gap_data_length_update, but it is now added. It did not affect the outcome,

however.

1745 case BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST:
1746 {
1747 ble_gap_data_length_params_t dl_params =
1748 {
1749 .max_tx_octets = BLE_GAP_DATA_LENGTH_AUTO,
1750 .max_rx_octets = BLE_GAP_DATA_LENGTH_AUTO,
1751 };
1752
1753 ret_code_t err_code = sd_ble_gap_data_length_update(p_evt->conn_handle, &dl_params, NULL);
1754
1755 APP_ERROR_CHECK(err_code);
1756 } break;

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

bjorn-spockeli — Thu, 20 Feb 2020 13:46:56 GMT

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.

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

bjorn-spockeli — Thu, 20 Feb 2020 10:44:47 GMT

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