S132 3.0 MTU exchange not completing

[Ray]

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.

5. 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.

[Ray]

Ok, Hung Bui, this is truly confusing, but I think it may help us to figure this out. I am very careful when debugging, so here are the facts:

1. My app was seeing the exchange_mtu_request, but no evt_write or _evt_conn_param_update events, and hvx errors, all indicating that the mtu exchange failed to complete

2. Upon your recommendation, I compiled the hrs app and noticed that while it appeared to "connect" in the NRF Toolbox app, no "fake data" started flowing in.

3. I then made a small modification to the HRS app to use nrf_log to the serial console, and I verified that it had exactly the same behavior as my app

4. I went to sleep

5. I got your message this morning

6. I located and manually copied the PC10040.hex over to my nrf52

7. I tried the NRF Toolbox HRM app again, and IT NOW WORKS

8. Curiously, I went back to my own version of the HRM app and (without even recompiling it) I copied MY version of the HRS app hex over to the device, and IT NOW ALSO WORKS. (And yes, mine includes the softdevice as part of the hex, so it was a complete replacement.)

9. I just copied my original app (not HRS) over onto the device, and it still exhibits the mtu exchange failure

10. I copied my version of the HRS app over onto the device, and it still again works.

I really don't know what to make of this. Let me ask something very specific: Were any app-level changes made on the NRF Toolbox side to support this MTU change?

If so, this would explain two things:

1. It could be, by just some random chance, that iOS updated the NRF Toolbox app last night. That would be just so random, but it is possible.

2. I have made no changes to my own iOS app that I'm using to communicate with my nRF app. Is some change necessary in my own iOS app to enable MTU exchange to work? (I hope not.)

Your thoughts would again be appreciated. Again, I am not careless about this stuff, so I know that what I said above is exactly the sequence of events. Thanks.