nRF52810 S112 background reconnect issue

[dr9]

Hi,

I'm working through a number of the PCA10040e examples (SDK16 | S112 | nRF52810 - mouse and keyboard to be specific) and have noticed some irregular behavior when waking the peripheral from sleep.  After bonding, if you put the peripheral to sleep, and let the central go to sleep as well (screen locked/off, no audio playing, etc.) and then wake the peripheral, the connection is not reestablished.  To restore the connection, you have to restart the peripheral with the central awake (i.e. being moved, screen on, audio playing, etc.)  However, if the central is "awake" when the peripheral is woken up, the connection is restored as expected.

I tried this with a nRF52832 (same examples in PCA10040 with S132) and the issue does not present itself.  The connection is able to be reestablished with the central sleeping.  Is this something to do with the Soft Device?  I plan on running a set of sniffer traces this afternoon and will post the results.

Thanks

p.s. central is an iOS device at this time.

[dr9]

Not sure if it helps, but I did find that if I make a call to advertising_start() sometime after the peripheral is running, with the central still sleeping, it does connect. 

[Kenneth]

You can find in chapter 35 in the Apple Bluetooth guidelines some recommendations to parameters that should be used: https://developer.apple.com/accessories/Accessory-Design-Guidelines.pdf

For instance I believe the advertising_start() may start by doing directed advertisement, this is not recommended by apple, see chapter 35.3. So you may need to init advertisement module without directed advertisement enabled.

Apple also have some suggestions for advertisement intervals.

[Kenneth]

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

[dr9]

Kenneth said:

 pm_handler_secure_on_connection()

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.

[Kenneth]

dr9 said:

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

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.

 

dr9 said:

As expected, pressing a key yields no response from the central. 

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?

[dr9]

Kenneth said:

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: peripheral on, not connected to central:

peripheral on, connected to central:

-----end_edit

Yes - just did a clean build and capture:

Kenneth said:

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.

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

Kenneth said:

What iPhone and ios version was

iPhone 8, iOS 14.0.

[Kenneth]

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

[dr9]

Its being called in security_dispatcher.c 

snapshot of the call stack:

[Kenneth]

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

Best regards,
Kenneth

[dr9]

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:

[dr9]

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. 

[Kenneth]

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