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.

[Hung Bui]

@Ray: Do you have same problem when you test with the example from SDK v12 ? If you can record a sniffer trace, it would be clear which side trigger the MTU exchange, and to check if the nRF52 actually sends the MTU extrange response or not.

[Ray]

Fascinating that you made me try this. I went into the ble_peripheral/ble_app_hrs app, tweaked the sdk_config.h, and tried it with nRF Toolbox's HRM.

It connects, but doesn't do anything. No fake data being reported at all.

Then I added an NRF_LOG_INFO at the very top of on_ble_evt(), and here's the serial output:

sd_ble_enable: RAM START at 0x20002128

APP:INFO:Heart Rate Sensor Start!

APP:INFO:Fast Adverstising

BLE_GAP_EVT_CONNECTED

APP:INFO:Connected

BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST

In other words, I don't see a BLE_GATTC_EVT_EXCHANGE_MTU_RSP coming back in this example either, and it appears to be stuck in the very same way.

[Ray]

I should add that I don't have any ble sniffer hardware, and I'm operating in a fairly rudimentary dev/debug environment. I'm using mac GCC, and I use srec_cat to generate a composite hex with the SD and app, and then copy it to the MBED drive of my device.

I can do any "nrf_log" style of debugging you like, but I can't do hardware-level debugging/tracing.

This board is an extremely basic bare breakout board with an NRF52832 and nothing more.

Please do advise as to what to try next; thanks so much for paying attention to this.

[Hung Bui]

Hi Ray,

It seems like an interoperability issue. Could you let me know which central device you used ? And the version of the operating system on it ?

Do you have any nRF51 board/dongle ? If you have you can use it as the sniffer back end. You can have a look here

It works on Windows, MAC and Linux

[Ray]

The two central devices I have tried are iPhone 5 and iPhone 6s, both running iOS 9.3.5.

I will try the sniffer and will let you know what I find, Hung Bui.

Thank you again.