nRF52810 S112 background reconnect issue

RE: nRF52810 S112 background reconnect issue

Kenneth — Mon, 05 Oct 2020 07:51:54 GMT

[quote user="dr9"]Is there any way to detect the failed reconnect on the peripheral end and re-initiate?[/quote]

Your latest screenshot show that the peripheral do establish connection, link is encrypted, and it looks like it also can send battery notifications.

Maybe you can check if the sd_ble_gatts_hvx() that is sent for button presses are successfully executed? E.g. no error code when calling sd_ble_gatts_hvx(), and that you experience BLE_GATTS_EVT_HVN_TX_COMPLETE?

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s140.api.v7.2.0/group___b_l_e___g_a_t_t_s___h_v_n___m_s_c.html

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s140.api.v7.2.0/group___b_l_e___g_a_t_t_s___f_u_n_c_t_i_o_n_s.html?cp=4_7_4_1_2_4_2_4#ga313fe43c2e93267da668572e885945db

If you are not BLE_GATTS_EVT_HVN_TX_COMPLETE you could potentially use that as a indicator that the packet is not received, and thereby disconnect, start advertisement and re-connect.

Best regards,
Kenneth

RE: nRF52810 S112 background reconnect issue

dr9 — Sat, 03 Oct 2020 02:42:07 GMT

HI Kenneth,

[quote userid="2111" url="~/f/nordic-q-a/66239/nrf52810-s112-background-reconnect-issue/271942#271942"](e.g. if other phones also show the same, or if it affect normal usage when phone is not in sleep).[/quote]

Tested with an iPhone 11 - same result. Will have results on a couple of androids over the weekend.

I also began to rebuild in SDK14.2 so that I could use S132, but due to memory size constraints, it looks like I'll be unable to achieve the desired outcome going that route. I'm not expecting any real action from Apple. Is there any way to detect the failed reconnect on the peripheral end and re-initiate? If not, it looks like I'll be forced to step up to the nRF52832...

RE: nRF52810 S112 background reconnect issue

Kenneth — Thu, 01 Oct 2020 07:12:29 GMT

Yes, you may find these two links useful:
https://infocenter.nordicsemi.com/topic/struct_nrf52/struct/nrf52810_dev_kit.html
https://infocenter.nordicsemi.com/topic/comp_matrix_nrf52810/COMP/nrf52810/nrf52810_ble_qdid_qual_matrix.html

RE: nRF52810 S112 background reconnect issue

dr9 — Wed, 30 Sep 2020 17:42:16 GMT

Is there any chance that I can use SDK16 and S132 and the nRF52810?

RE: nRF52810 S112 background reconnect issue

dr9 — Tue, 29 Sep 2020 15:59:25 GMT

[quote userid="2111" url="~/f/nordic-q-a/66239/nrf52810-s112-background-reconnect-issue/271942#271942"]so doing a full clear cache on the phone side[/quote]

Unfortunately this made no difference.

I'm looking for a newer iPhone to see if the behavior is any different there. If its not, I may be stuck going to a nRF52832 chip or completely rebuilding my application in SDK14.2.

[quote userid="2111" url="~/f/nordic-q-a/66239/nrf52810-s112-background-reconnect-issue/271942#271942"]or if it affect normal usage when phone is not in sleep[/quote]

If the phone is not asleep, there is no issue at all.

RE: nRF52810 S112 background reconnect issue

Kenneth — Tue, 29 Sep 2020 07:23:02 GMT

The way I see this is that the phone in this case have a bug of some sort (could be an internal race condition of some sort). It may be triggered by the content of the LL_FEATURE_RSP, since that is slightly different between S112 and S132.

It can also be that the actual issue is triggered from the very first time the two devices bonded (e.g. some data not stored as it should be), so doing a full clear cache on the phone side (e.g. remove device from the BT listing and turn off/on BT) and re-bond could be worth a try. Just make sure that re-bonding is done without the pm_handler_secure_on_connection()/pm_handler_on_pm_evt() on the peripheral device.

Let me know if you have any new findings (e.g. if other phones also show the same, or if it affect normal usage when phone is not in sleep).

RE: nRF52810 S112 background reconnect issue

dr9 — Mon, 28 Sep 2020 21:42:25 GMT

For what its worth, I grabbed a copy of SDK 14.2 and followed the instructions here to convert the emulated keyboard project from S112 to S132 (v5.1). This resulted in as-expected reconnection behavior. I'm considering reworking my application (developed in SDK 16) in SDK14.2, but would rather see this function in SDK 16.

RE: nRF52810 S112 background reconnect issue

dr9 — Mon, 28 Sep 2020 19:57:38 GMT

That took care of the Rcvd Security Request: AuthReq: Bonding packet shown in the sniffer, but did not help with the re-connection issue.

Connects:

Doesn't connect:

RE: nRF52810 S112 background reconnect issue

Kenneth — Mon, 28 Sep 2020 19:33:16 GMT

Seems this can be called from two places, please comment out pm_handler_on_pm_evt() in pm_evt_handler().

Best regards,
Kenneth

RE: nRF52810 S112 background reconnect issue

dr9 — Mon, 28 Sep 2020 19:18:50 GMT

Its being called in security_dispatcher.c

snapshot of the call stack:

RE: nRF52810 S112 background reconnect issue

Kenneth — Mon, 28 Sep 2020 19:12:46 GMT

Can you try to trace back in your code to where sd_ble_gap_authenticate() may be called? I assume setting a breakpoint may help, since it shouldn't be called here.

Best regards,
Kenneth

RE: nRF52810 S112 background reconnect issue

dr9 — Mon, 28 Sep 2020 18:56:08 GMT

[quote userid="2111" url="~/f/nordic-q-a/66239/nrf52810-s112-background-reconnect-issue/271877#271877"]But neither working or failing log show any key presses (that should trigger a notification for the key press), only battery level notification is shown:[/quote]

EDIT: peripheral on, not connected to central:

peripheral on, connected to central:

-----end_edit

Yes - just did a clean build and capture:

[quote userid="2111" url="~/f/nordic-q-a/66239/nrf52810-s112-background-reconnect-issue/271877#271877"]Are you sure? Because the trace do show SMP request on both 12646 and 11661, then something else must be calling the security request in your code.[/quote]

edit: I only found pm_handler_secure_on_connection() being called in peer_manager_handler.c

[quote userid="2111" url="~/f/nordic-q-a/66239/nrf52810-s112-background-reconnect-issue/271877#271877"]What iPhone and ios version was[/quote]

iPhone 8, iOS 14.0.

RE: nRF52810 S112 background reconnect issue

Kenneth — Mon, 28 Sep 2020 18:43:39 GMT

[quote user="dr9"]was commented out in peer_manager_handler.c for the build associated with that trace.[/quote]

Are you sure? Because the trace do show SMP request on both 12646 and 11661, then something else must be calling the security request in your code.

[quote user="dr9"]As expected, pressing a key yields no response from the central. [/quote]

But neither working or failing log show any key presses (that should trigger a notification for the key press), only battery level notification is shown:

Edit: Something is not as it should be here: the central is writing multiple write requests with the value of 00 to the same handle (0x001e). This isn't really an issue and is allowed to do, but seems unnecessary. What iPhone and ios version was 20200925 - full capture.pcapng?

RE: nRF52810 S112 background reconnect issue

dr9 — Mon, 28 Sep 2020 15:49:49 GMT

[quote userid="2111" url="~/f/nordic-q-a/66239/nrf52810-s112-background-reconnect-issue/271778#271778"] pm_handler_secure_on_connection()[/quote]

was commented out in peer_manager_handler.c for the build associated with that trace.

When I wake the central after waking the peripheral, the peripheral shows as "not connected" in the central's Bluetooth devices list. As expected, pressing a key yields no response from the central.

If I compile and build this to a nRF52832 using S112, the same behavior is observed. If I build with S132, the peripheral reconnects in the background without an issue. By elimination, it looks like the differences in S112 and S132 somehow contribute to the difference in behavior. Thoughts?

And yes, I'll reach out to Apple, too.

RE: nRF52810 S112 background reconnect issue

Kenneth — Mon, 28 Sep 2020 12:33:38 GMT

Please comment out pm_handler_secure_on_connection(), since that break with the apple guidelines chapter 35.10.

I am not sure if I understand what is actually failing, because both instances show that the peers do connect, they encrypt, and for instance the battery level is notified from the peripheral to the central every 2 seconds. So I guess the question is, what is not working here? What happens if you for instance press a key?

There is nothing in the logs that indicate an issue with the peripheral, so if the phone behave differently then I suggest contacting apple on this issue.

The logs do show that the phone for one of the connections do also execute a write to the CCCD's, however the application on the peripheral do not require this, as the CCCD's are already stored from previous connection and thereby restored on connection (which is why the battery level notification works in both cases).

Best regards,
Kenneth

RE: nRF52810 S112 background reconnect issue

dr9 — Fri, 25 Sep 2020 23:22:33 GMT

Finally got this working. Lines 11659-12577 represent a failed reconnect effort. Lines 12642-13580 represent a successful one. The firs obvious difference is that an MTU exchange is not happening. Beyond that, I'm unsure where to look for clues as to what is not working properly.devzone.nordicsemi.com/.../20200925-_2D00_-full-capture.pcapng

RE: nRF52810 S112 background reconnect issue

Kenneth — Fri, 25 Sep 2020 09:11:06 GMT

The LTK should be:
uint8_t ltk[BLE_GAP_SEC_KEY_LEN]; /**< Long Term Key. */

You may set a breakpoint in your project just to read out the LTK, since it doesn't change you only need to read it once and it will be valid until you re-bond. After reading out the LTK you can then disconnect the debugger and run the application as normal with the nRF Sniffer.

RE: nRF52810 S112 background reconnect issue

dr9 — Thu, 24 Sep 2020 19:43:53 GMT

I have a hex word printing from a debug terminal that I can enter into the passkey field. Is this what you are looking for?

RE: nRF52810 S112 background reconnect issue

dr9 — Thu, 24 Sep 2020 18:37:00 GMT

Yes - I agree. I'm just surprised that the issue doesn't present itself with other chips/softdevices.

Tried forcing 1MBPS in the ble_evt_handler() but observed no difference. Will be trying per your edits next.

RE: nRF52810 S112 background reconnect issue

Kenneth — Thu, 24 Sep 2020 18:20:53 GMT

Doesn't make much sense, sounds like an issue on phone side. But maybe you can change from BLE_GAP_PHY_AUTO to BLE_GAP_PHY_1MBPS in ble_evt_handler() to see if there is any difference:

        case BLE_GAP_EVT_PHY_UPDATE_REQUEST:
        {
            NRF_LOG_DEBUG("PHY update request.");
            ble_gap_phys_t const phys =
            {
                .rx_phys = BLE_GAP_PHY_1MBPS, // BLE_GAP_PHY_AUTO,
                .tx_phys = BLE_GAP_PHY_1MBPS, // BLE_GAP_PHY_AUTO,
            };
            err_code = sd_ble_gap_phy_update(p_ble_evt->evt.gap_evt.conn_handle, &phys);
            APP_ERROR_CHECK(err_code);
        } break;

Unfortunately the sniffer log is encrypted, so difficult to know exactly what is happening, this means we need the LTK to decrypt the data.

To output the LTK the easiest may be to call pm_peer_data_bonding_load() to get the LTK, this can for instance be done after PM_EVT_PEER_DATA_UPDATE_SUCCEEDED or PM_EVT_CONN_SEC_SUCCEEDED event in pm_evt_handler() in main.c.

pm_peer_data_bonding_t peer_bonding_data;

pm_peer_data_bonding_load(m_peer_id, peer_bonding_data);

//16byte LTK in peer_bonding_data.own_ltk.enc_info.ltk;

I believe (hope) that the LTK can be inserted in wireshark the same way as legacy pairing with OOB:

https://infocenter.nordicsemi.com/topic/ug_sniffer_ble/UG/sniffer_ble/action_paired.html

I am not sure what is MSB and LSB in this case, so you may need to try both orders of the 16bytes LTK.

RE: nRF52810 S112 background reconnect issue

dr9 — Thu, 24 Sep 2020 15:31:54 GMT

Same behavior with pm_handler_secure_on_connection() commented out in peer_manager_handler.c

Sniffer logs attached.

devzone.nordicsemi.com/.../20200924-_2D00_-sniffer_5F00_doesnt_5F00_connect.pcapng

devzone.nordicsemi.com/.../20200924-_2D00_-sniffer_5F00_connects.pcapng

I'm not sure if it means anything, but in the log where the connection isn't established, the PHY shifts from 1M to 2M at line 42. On the log showing a successful connection, it stays in 1M for the duration.

RE: nRF52810 S112 background reconnect issue

Kenneth — Thu, 24 Sep 2020 12:18:27 GMT

Looks like all logs connect here, and all logs also indicate the link is encrypted. So I guess this point to a different reason than it's not connecting?

Can you try to comment out pm_handler_secure_on_connection() in your application?

RE: nRF52810 S112 background reconnect issue

dr9 — Wed, 23 Sep 2020 21:33:13 GMT

adding a second set of traces in case you want to see multiple samples.devzone.nordicsemi.com/.../20200923-_2D00_-sniffer_5F00_connects-_2D00_-2.pcapng devzone.nordicsemi.com/.../20200923-_2D00_-sniffer_5F00_doesnt_5F00_connect-_2D00_-2.pcapng

RE: nRF52810 S112 background reconnect issue

dr9 — Wed, 23 Sep 2020 20:50:28 GMT

[quote userid="88349" url="~/f/nordic-q-a/66239/nrf52810-s112-background-reconnect-issue/271185"]Might be something with the older iOS. I'm updating that phone now, too.[/quote]

Updated to iOS 14 - no change in behavior observed.

Sniffer traces are attached.

The trace titled "...sniffer_connects" represents what happens when the peripheral wakes up while the central is awake. The trace titled "...sniffer_doesn't_connect" represents what happens when the peripheral wakes up while the central is asleep.

devzone.nordicsemi.com/.../3681.20200923-_2D00_-sniffer_5F00_connects.pcapng

devzone.nordicsemi.com/.../6327.20200923-_2D00_-sniffer_5F00_doesnt_5F00_connect.pcapng

RE: nRF52810 S112 background reconnect issue

dr9 — Wed, 23 Sep 2020 17:36:57 GMT

Getting the sniffer running shortly.

Initial test phone was an 8 running iOS13.3.1. I just tested it on an iPad Pro running 13.7 and it works fine!

Might be something with the older iOS. I'm updating that phone now, too.