HCI core raises error and BLE transmissions stop

[Malek Itani]

I'm trying to transmit audio data between two nRF5340DKs. These boards share timestamp information via the wireless time synchronization method here: https://github.com/nordic-auko/nRF5-ble-timesync-demo. This code uses then radio peripheral directly contains some time-critical operations and has some high-priority routines. It exists on the netcore and coexists with the bluetooth controller. I just extended the hci_ipc source code with my own custom IPC service to control this timesync code from the appcore.

My program is correctly able to transmit both audio data as well as timestamp information between the two devices for a while. After a minute or so, the bluetooth HCI raises an error, and the bluetooth transmissions stop. The specific error thrown isn't always the same. Most commonly, it is:

<err> bt_hci_core: evt num_handles (=212) too large (849 > 5)

Sometimes, this error is accompanied by:
<wrn> bt_hci_core: Unexpected HOST_NUM_COMPLETED_PACKETS (status 0x12)

Do you have any advice on how to debug this?

[tesc]

Hi,

The current nRF5-ble-timesync-demo implementation for nRF Connect SDK is for SDK version 2.8.0. Is there any particular reason why you are using an older SDK version? It might be as simple as an SDK version mismatch leading to issues, in which case using matching SDK versions would solve the issue.

The error message of <err> bt_hci_core: evt num_handles (=212) too large (849 > 5) seems to indicate that a HCI message, sent between BLE host and BLE controller, is larger than the buffer size for storing the HCI message. The particular HCI message (containing a num_handles event) has to do with keeping track of the HCI message passing itself.

Regarding the <wrn> bt_hci_core: Unexpected HOST_NUM_COMPLETED_PACKETS (status 0x12) warning, I do not find any prior occurrences with the 0x12 status value here on DevZone. Nevertheless, 0x12 means "Invalid HCI Command Parameters". If there is something wrong with the message, along the lines indicated by the error message, this kind of warning would not be too surprising.

Have you reproduced the error using corresponding SDK versions?

Have you done a debug session, in order to figure out when and where (in terms of your application) the error occurs?

Have you done BLE sniffing to see what happens over-the-air leading up to the error?

Regards,
Terje