Reasons for 0x22 error on disconnection

[jeffdev3]

I am seeing many 0x22 error codes on the disconnect event when I connect to an iPhone with 5.2/5.3 BT version.  I do not see the 0x22 error when connecting to iPhones with 5.1 BT such as the iPhone XR or Android phones.  I am experiencing this in my custom product using Softdevice 7 but I can reproduce the problem in the NCS peripheral example project using Zephyr and the PCA10040 devkit.  In the NCS example, the 0x22 only happens if I use the Nordic stack.  It does not occur with the open source stack.  In the peripheral example, I made these changes to cause the 0x22 error:

After connection, change connection interval to 2s

Wait 6s and disconnect

I attached the Ellisys captures of the Nordic and open source stack.  The Nordic capture has 2 markers when the 0x22 error occurred.  It seems to be related to the Channel Map Indication sent by the phone but in my custom product I have seen the 0x22 error when no Channel Map Indication is sent.  Is there a list of reasons for why I can see 0x22 error on disconnect?

z-nordic.bttz-open.btt

[Einar Thorsrud]

Hi,

We have started to look into this and have some questions:

• Which nRF Connect SDK version are you using?
• Can you share the modified example project you used to reproduce the issue?
• Can  you specify the exact iPhone models and iOS versions you have seen this issue with?

[jeffdev3]

I am using NCS 2.4.2 and iPhone 12 Mini.  I attached the project used.

4682.peripheral.zip

[Einar Thorsrud]

Hi,

Thank you for the project. We have tested your project (with CONFIG_BT_LL_SW_SPLIT=n) with an iPhone 12 and and iPhone 15 Pro with iOS 17.1.0, but not been able to reproduce yet. So far we have only seen 0x16 as disconnect reason, which is expected. Which iOS version do you have on the phone you reproduce it with? And do you see it consistently?

That said, our Bluetooth stack team is looking into this and have spotted a potential issue in the SoftDevice controller that may explain what you are seeing. So we are continuing to look into this.

Update: We have been able to reproduce on an iPhone (but no longer after updating to iOS 17.1.0).

[jeffdev3]

I have seen the problem on iOS 16.x and 17.0.1 usually within 20 connections.  I will update to 17.1 and try.

[Einar Thorsrud]

Hi,

We have identified an issue in the SoftDevice Controller which we believe is the cause of what you have reported. This will be fixed in a future nRF Connect SDK release.

[jeffdev3]

I am still able to reproduce the problem after upgrading to iOS 17.1 on an iPhone 12 Mini.  Can you explain what the issue is in the SoftDevice and what the consequences are of not fixing it?  My product is based on SoftDevice 7.0.1 and doesn't use the nRF Connect SDK so I will not be able to incorporate the fix.  Thank you.

[Einar Thorsrud]

Hi,

The issue is that when receiving a channel map update as a peripheral, the channel is selected using the old channel map when the instant occurs. So the first packet after a channel map update will be lost and retransmitted. This is not a serious issue (which may be why it has not been found before), but may lead to lightly lower performance due to packet loss when connected to a central that does a lot of channel pap updates.

This causes the behavior you reported, where the peripheral disconnects, and the ACK from the central to the termination happens at the instant of a channel map update, and is not received due to this bug. This will cause the peripheral to wait the supervision timeout before disconnecting and generate a timeout event (0x22 in this case). This is the same as will happen if there is interference when the ACK from the central is sent, and we get a CRC error.

This will be fixed in the SoftDevice Controller, but there are no plans to fix the old SoftDevices. The consequences are low as channel map updates are typically not very frequent, and the same behavior can occur doe to packet loss caused by other reasons.