We have a peripheral device that maintains a PAwR sync (as a syncer/responder), connects to another peripheral in a central role, and also accepts connections from a central.
We were seeing SDC assertion failures (13, 451) (see SDC Assertion 13, 451 ), so I've applied the workarounds for known issues NCSDK-31528 and NCSDK-35430. When the central initiates a connection during an active PAwR sync, I now see repeated HCI command failures:
[01:00:04.412,475] <err> bt_hci_core: bt_hci_cmd_send: Unable to send to driver (err -1)
[01:00:04.912,475] <err> bt_hci_core: bt_hci_cmd_send: Unable to send to driver (err -1)
[01:00:05.912,475] <err> bt_hci_core: bt_hci_cmd_send: Unable to send to driver (err -1)
[01:00:06.912,628] <err> bt_hci_core: bt_hci_cmd_send: Unable to send to driver (err -1)
I've traced this to hci_internal_cmd_put in nrf/subsys/bluetooth/controller/hci_internal.c.
When LE_Set_Periodic_Advertising_Response_Data is issued, the command_complete is deferred until the subevent completes, and padv_response_data_cmd_pending is set to true. While this flag is set, hci_internal_cmd_put returns -NRF_EPERM for all HCI commands. The Zephyr BT host (hci_core_send_cmd in zephyr/subsys/bluetooth/host/hci_core.c) does not retry commands that fail at the driver level. When bt_send returns an error, it calls hci_cmd_done with BT_HCI_ERR_UNSPECIFIED and moves on. This means the failure is permanent - there is no recovery path.
Since the PAwR recv_cb fires on every subevent and immediately queues a new response, padv_response_data_cmd_pending can be almost continuously true, leaving very narrow windows where other HCI commands can succeed.
Is there a recommended way to handle concurrent HCI command submission alongside PAwR response data operations? We need to maintain both a PAwR sync (with responses on every subevent) and connections to other devices simultaneously. The current behaviour makes this combination unreliable, since we cannot predict when a central will initiate a connection.
