S132 3.0 MTU exchange not completing

RE: S132 3.0 MTU exchange not completing

Hung Bui — Mon, 26 Sep 2016 11:39:09 GMT

@Ray: we don't have staff working in the weekend. Your case will be handled today. But since it's the incompatibility issue with a third party device, it's not 100% sure that the solution is in our hand.

RE: S132 3.0 MTU exchange not completing

Ray — Sat, 24 Sep 2016 17:07:06 GMT

Hung Bui - you may find it interesting to know that I have yet another SDK12/nRF52 incompatibility problem, and it would be great if you or someone could weigh in.

Luckily, this time I know how to use the sniffer!

Here is the forum entry:

devzone.nordicsemi.com/.../

And since there were no replies, I also submitted a support case:

www.nordicsemi.com/.../31801

RE: S132 3.0 MTU exchange not completing

Hung Bui — Tue, 13 Sep 2016 07:50:03 GMT

No problem, Ray. Please inform me if it comes back :)

RE: S132 3.0 MTU exchange not completing

Ray — Mon, 12 Sep 2016 16:43:35 GMT

I'm not sure where the _RSP is handled in the code, but it's not being swallowed in my code. Regardless, it doesn't matter because I have no need to deal with the _RSP message. I was just curious.

I did indeed validate that by removing the mtu_reply() call, it stopped working again. And by placing the mtu_reply() call back in, it works again.

Thanks for the tip on wireshark filtering.

As you sensed, I do have more than a bit of anxiety about this problem's intermittent/inconsistent nature. That said, at this moment there is really nothing I can do but to wait for it to happen again. At least now I am armed with the ability to sniff.

Thanks for getting me to this point, and I'll talk with you again if/when I can get it to repro. Thx, Hung.

RE: S132 3.0 MTU exchange not completing

Hung Bui — Mon, 12 Sep 2016 13:49:11 GMT

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:

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.

RE: S132 3.0 MTU exchange not completing

Ray — Sun, 11 Sep 2016 20:19:25 GMT

Not sure how to do an attachment, so here's the link:

dl.dropboxusercontent.com/.../raycap.pcapng

RE: S132 3.0 MTU exchange not completing

Ray — Sun, 11 Sep 2016 20:17:46 GMT

So, Hung Bui, thank you for the sniffer recommendation. That said, I am very, very frustrated and I'd love it if you could just give me your intuition about what may be happening.

I hope that at this point I have impressed upon you that I don't do this debugging carelessly, and so when I say something it is really factually what I experienced.

The morning after writing my last reply to you, I did indeed validate the error checking. It was fine.

And so I ordered the sniffer.

Yesterday the sniffer arrived, and today I sat down to install and try it. (This is quite nice, by the way. I watched your video and it was quite helpful. My only constructive feedback is that trying to use it on a mac is a little frustrating because it doesn't seem to be officially supported in the downloads, and the one that I did end up finding doesn't work with the latest wireshark. But I did manage to install the old version of wireshark, and it's working fine now.)

As soon as the sniffer was up and running, I connected my device. Note that between the last time it was failing and now,

I have NOT updated the firmware on that failing device (the peripheral)
I have NOT done anything else to my phone (the controlelr) in terms of changing versions or config of anything.

And so even before doing a capture, I connected the device and watched the serial console fully expecting to see the bug happen, since my device has NEVER worked properly in this testing.

Unbelievably, my device worked. Although I still don't seem to receive the BLE_GATTC_EVT_EXCHANGE_MTU_RSP, immediately after my BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST and my calling sd_ble_gatts_exchange_mtu_reply(), I did receive a BLE_GATTS_EVT_WRITE which set up notification parameters properly, and everything in my app proceeded to work perfectly.

This leaves me in the position at this point of asking three questions:

Why, when I had isolated it earlier in this thread, did the HRS app fail repeatably with the app being "stuck" in the MTU Exchange state, and then one morning (without any changes) it just started working?
Why, when I had never before had my own app working, being "stuck" in the MTU Exchange state, did it suddenly start working today without any changes at all - that is, without even re-burning a new version of my app to the device?
More because I am curious, why does my app not seem to receive a BLE_GATTC_EVT_EXCHANGE_MTU_RSP event, even though the doc says that it should?

I've never looked at OTA bluetooth so I'm incapable of evaluating a capture, so I'm including one as an attachment here.

I'm truly nervous about this, Hung Bui, because I can't afford to just switch to SDKv12 and have it randomly succeed and randomly fail in the field. Anything you can do to help ponder this with the engineers would be appreciated.

Thanks.

RE: S132 3.0 MTU exchange not completing

Ray — Thu, 08 Sep 2016 13:25:26 GMT

Ok thanks. I ran out of time today, but my priorities on this project will be:

Ensure that my error checking is being done, as you say
Try to get sniffer working, just to validate what is going on
Simplify/isolate further. (Hard to do because this is a complex app that is both a controller and a peripheral role, but if necessary I will take out a machete and start hacking away.)

Thanks for your perseverance.

RE: S132 3.0 MTU exchange not completing

Hung Bui — Thu, 08 Sep 2016 13:21:13 GMT

Oh, I'm sorry I misread that everything suddenly worked today, including your app.

You would need to make sure BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST actually arrived, and you put the MTU size to gatt_enable_params.att_mtu correctly. You should check all the return code when you call either softdevice_enable() or the sd_ble_gatts_exchange_mtu_reply() they should return success.

My suggestion is to modify your app to a very simple one. Maybe just keep a dummy characteristic that you can use to send notification, just to check it MTU exchange finished or not. If you can make simple example that can reproduce the issue, you can send to use and we test here. If we can also reproduce the issue here, it will be fixed very quickly.

RE: S132 3.0 MTU exchange not completing

Ray — Thu, 08 Sep 2016 13:01:12 GMT

I should add, for whatever it's worth, that the problem exhibits itself in my app even if I just try to connect into it using the nRF Connect app.

RE: S132 3.0 MTU exchange not completing

Ray — Thu, 08 Sep 2016 12:52:18 GMT

Well, my app is still broken even though the sample is now working. Can you give me some idea of what conditions would cause the MTU reply not to be sent? I am dead in the water here in terms of using SDKV12 until I can get this worked out.

Is the source code available somewhere that would let me inspect or at least debug the logic that would cause a failure to get the reply?

RE: S132 3.0 MTU exchange not completing

Hung Bui — Thu, 08 Sep 2016 12:45:01 GMT

Hi Ray,

We haven't released any update for nRFToolbox or nRF Connect in the last few days. And I don't think it could do anything with the MTU exchange.

When releasing the S132 v3.0 we did have IOP testing process that we tested with many phones and devices. There is of course a chance that updates of the iOS or some devices are not in the list of devices we have here can cause an issue.

MTU exchange on iOS has always been there for long time maybe from iOS v6. It was handled automatically by the softdevice before, but now we allow larger MTU size than 23 and we give the application the option to choose which MTU size should be used.

If you see the problem occurs again, please let me know.

RE: S132 3.0 MTU exchange not completing

Ray — Thu, 08 Sep 2016 12:24:03 GMT

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:

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
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.
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
I went to sleep
I got your message this morning
I located and manually copied the PC10040.hex over to my nrf52
I tried the NRF Toolbox HRM app again, and IT NOW WORKS
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.)
I just copied my original app (not HRS) over onto the device, and it still exhibits the mtu exchange failure
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:

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

RE: S132 3.0 MTU exchange not completing

Ray — Thu, 08 Sep 2016 11:59:23 GMT

I wish I knew that! I just ordered this one from digi-key for $51 plus another $60 for overnight delivery so I could get you debug info before I fly out of town! sigh! www.digikey.com/.../5022448

RE: S132 3.0 MTU exchange not completing

Hung Bui — Thu, 08 Sep 2016 11:56:33 GMT

@Ray: If the UART pins are the same with the UART pins on our DK/Dongle, it should work. Or you can order one, the price for a nRF51 DK/Dongle board is pretty low now, $39 :)

RE: S132 3.0 MTU exchange not completing

Ray — Thu, 08 Sep 2016 11:53:10 GMT

Indeed I used the HRS sample with the HRM app.

I am just getting started for the day but only have an hour or so.

Do you by chance know if the BLE Sniffer works with the RedBear Labs MK20 dongle?

RE: S132 3.0 MTU exchange not completing

Hung Bui — Thu, 08 Sep 2016 11:48:32 GMT

Hi Ray,

Which app did you use to test ? Could you please try with NRF Connect ? I just tested here with iPhone6s and iPad 5(?) both 9.3.5 and it worked fine, MTU response sent by the nRF52 properly and notification came after I enabled CCCD.

Please also try with the precompiled hex file comes with the SDK. The sniffer trace can really tell.

RE: S132 3.0 MTU exchange not completing

Ray — Thu, 08 Sep 2016 10:56:27 GMT

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.

RE: S132 3.0 MTU exchange not completing

Hung Bui — Thu, 08 Sep 2016 07:13:01 GMT

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

RE: S132 3.0 MTU exchange not completing

Ray — Wed, 07 Sep 2016 16:22:59 GMT

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.

RE: S132 3.0 MTU exchange not completing

Ray — Wed, 07 Sep 2016 16:18:53 GMT

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.

RE: S132 3.0 MTU exchange not completing

Hung Bui — Wed, 07 Sep 2016 14:40:07 GMT

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