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

S132 3.0 MTU exchange not completing

  1. I looked at examples and added identical code to my own app, specifically to a) set the gatt_enable_params.att_mtu to GATT_MTU_SIZE_DEFAULT, and b) to handle BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST in evt dispatch by doing an sd_ble_gatts_exchange_mtu_reply of that same size.

  2. I found that when testing my app, just after an incoming CONNECT succeeds, when I try to do an sd_ble_gatts_hvx, it is returning NRF_ERROR_INVALID_STATE.

  3. I found the doc of the new functionality of Configurable ATT_MTU on P.6 of the S132 migration document, which was great. I also saw this in the Usage section, which was also a relief because it explains the invalid state. This must mean that the exchange is currently still in progress. "HVx and service changed cannot run while a local client initiated ATT_MTU exchange is active. The SV calls sd_ble_gatts_hvx( ) and sd_ble_gatts_service_changed() will return NRF_ERROR_INVALID_STATE if a local client initiated ATT_MTU exchange is ongoing."

  4. I instrumented my app to use NRF_LOG to output all BLE messages to the serial console, and see the following:

a) BLE_GAP_EVT_CONNECTED (which has a good handle)

b) BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST (which I handle with the sd_ble_gatts_exchange_mtu_reply as I said above, and as in all the samples)

c) Nothing else. I never receive the BLE_GATTC_EVT_EXCHANGE_MTU_RSP which the doc would imply I should be receiving to indicate the end of the exchange.

  1. I read this doc, and anything else I could find, and I am stumped as to why the RSP isn't coming, and why I'm stuck in the middle of the MTU exchange. I don't even know who is originathing this request, so I can't look at the source code to see what is happening. infocenter.nordicsemi.com/index.jsp

I'm completely blocked in my conversion to SDKV12 at this point because of nonfunctional BT. Guidance would be greatly appreciated. Thank you.

Parents
  • Hi Ray,

    I'm sorry to hear that you had inconsistent results. From the trace I can see that the MTU request has been sent from the central side, and the MTU response been replied from the peripheral side, as it should. I would assume it's handled some where in the code. You can test this by comment out the code handling sd_ble_gatts_exchange_mtu_reply() and check if it still works.

    You can see the request and response here:

    image description

    If you are using Wireshark v1.10 (as recommended) you can filter out empty packet by using this filter "!(btle.length == 0)" as in the video.

    From now you have the sniffer so you can capture the trace when the issue occurs. It will be clearer of what could go wrong.

    From the trace I assume you used slave latency = 3. Also please put the sniffer closer to your device as I can see some Malformed packet occurred.

Reply
  • Hi Ray,

    I'm sorry to hear that you had inconsistent results. From the trace I can see that the MTU request has been sent from the central side, and the MTU response been replied from the peripheral side, as it should. I would assume it's handled some where in the code. You can test this by comment out the code handling sd_ble_gatts_exchange_mtu_reply() and check if it still works.

    You can see the request and response here:

    image description

    If you are using Wireshark v1.10 (as recommended) you can filter out empty packet by using this filter "!(btle.length == 0)" as in the video.

    From now you have the sniffer so you can capture the trace when the issue occurs. It will be clearer of what could go wrong.

    From the trace I assume you used slave latency = 3. Also please put the sniffer closer to your device as I can see some Malformed packet occurred.

Children
Related