Hi,
We did stumble upon an issue with our BLE peripheral running on an nRF52832 with Softdevice S132 5.0.0 . The central side is implemented on top of the UWP (Universal Windows Platform) Bluetooth LE API.
The MO we observe using the nRF Sniffer is that our peripheral issues a LL_PHY_REQ (through a call to sd_ble_gap_phy_update()). After the peer responds with LL_PHY_UPDATE_IND, there is no further BLE communication until the Softdevice issues a BLE_GAP_EVT_DISCONNECTED with reason set to BLE_HCI_CONNECTION_TIMEOUT.
See for example the following excerpt from a sniffer log:
3238 61.073 Master_0xa24eb1c1 LE 1M ATT 11 59617 1 1 False 13 Sent Read By Type Request, GATT Characteristic Declaration, Handles: 0x0001..0x0009 3239 61.074 Slave_0xa24eb1c1 LE 1M LE LL 0 151 1 0 False 13 Empty PDU 3240 61.075 Master_0xa24eb1c1 LE 1M LE LL 0 59601 0 0 False 14 Empty PDU 3241 61.077 Slave_0xa24eb1c1 LE 1M LE LL 3 150 0 1 True 14 Control Opcode: LL_PHY_REQ 3242 61.078 Master_0xa24eb1c1 LE 1M LE LL 0 150 1 1 False 14 Empty PDU 3243 61.180 Master_0xa24eb1c1 LE 1M LE LL 0 59436 1 1 True 15 Empty PDU 3244 61.181 Slave_0xa24eb1c1 LE 1M ATT 34 150 1 0 False 15 Rcvd Read By Type Response, Attribute List Length: 4, Device Name, Appearance, Peripheral Preferred Connection Parameters, Central Address Resolution 3245 61.182 Master_0xa24eb1c1 LE 1M LE LL 5 150 0 0 False 15 Control Opcode: LL_PHY_UPDATE_IND 3246 70.839 c9:1b:a0:99:b9:f6 LE 1M LE LL 36 9667815 0 ADV_NONCONN_IND
The issue does not always occur, but what I observed when looking at the sniffer traces is:
- In those instances where the timeout occurs, the LL_PHY_REQ is issued while another request during service discovery is pending, e.g. a "Read by Type Request" or a "Read Information Request". I.e. the central issued this request and before the Nordic responds, our peripheral firmware triggers the LL_PHY_REQ.
- The LL_PHY_UPDATED_IND seems to be issued in the same connection event in which the response to the pending request is issued.
- Those instances where the procedure works flawlessly, there are no other coinciding requests requiring responses, the LL_PHY_UPDATE_IND comes in its own Connection event.
The following sniffer excerpt shows an instance where no connection timeout occurs.
2044 29.951 Master_0xaf9aba17 LE 1M ATT 65 89587 1 0 False 61 Sent Write Command, Handle: 0x0017 (Unknown: Unknown) 2045 29.951 Slave_0xaf9aba17 LE 1M LE LL 3 150 0 0 False 61 Control Opcode: LL_PHY_REQ 2046 30.052 Master_0xaf9aba17 LE 1M LE LL 5 44145 0 1 False 62 Control Opcode: LL_PHY_UPDATE_IND 2047 30.054 Slave_0xaf9aba17 LE 1M LE LL 0 151 1 1 False 62 Empty PDU 2048 30.055 Master_0xaf9aba17 LE 1M LE LL 0 44648 1 0 False 63 Empty PDU
As a workaround we will for now try to either delay the LL_PHY_REQ for a few seconds so it will not coincide with service discovery or even disable it altogether.
Do you have an idea what the cause of this problem may be?
Best regards,
-mike
