Hello Nordic Team,
I am having issues with the HCI UART firmware for the nRF52840 on the Thingy91. I have been using the HCI UART firmware from nRF Connect SDK 1.0.0 for some time but recently I ported over the changes from nRF Connect SDK 1.3.0 and I have since ran into issues.
My application is similar to the LTE BLE Gateway application in that I am using the nRF52840 as a bluetooth controller to scan for nearby bluetooth devices. I have also used the patches provided by Sigurd on the following ticket: https://devzone.nordicsemi.com/f/nordic-q-a/52689/nrf9160-lte-sensor-gateway-on-thingy-91/230300#230300 to support this on the Thingy91.
With the nRF Connect SDK v1.0.0 HCI UART firmware, I would occasionally see the following from the RTT logging on the nRF9160:00> [00:16:23.539,947] <wrn> bt_driver: Discarding event 0x3e
but now with the nRF Connect SDK v1.3.0 HCI UART firmware, I get a bunch of these types of messages printed out (in addition to the message above):00> [00:17:13.480,102] <err> bt_driver: Not enough space in buffer00> [00:17:14.016,693] <err> bt_driver: Unknown H:4 type 0x4900> [00:17:14.017,028] <err> bt_driver: Unknown H:4 type 0x0e00> [00:17:14.017,364] <err> bt_driver: Unknown H:4 type 0x2f00> [00:17:14.017,669] <err> bt_driver: Unknown H:4 type 0x6e00> [00:17:14.018,005] <err> bt_driver: Unknown H:4 type 0xec00> [00:17:14.018,341] <err> bt_driver: Unknown H:4 type 0x1e00> [00:16:29.435,485] <wrn> bt_hci_core: Unhandled event 0x01 len 41: 0301da972fdf98fa1e02010403039afe16169afe1181820179ececd817b280e2e31edd480ac101bc04The behavior of the firmware is also affected - usually after the "Unhandled event" message as seen above, the bluetooth scan will be provide no results for 30-60 seconds before it recovers. This differs from the nRF Connect SDK v1.0.0 HCI UART firmware, as the bluetooth scan would still provide results regardless of the "Discarded event" message.Any ideas?Thank you,Cody
It looks like the queue size requirements has changed for your specific scenario between releases.
According to this zephyr-issue, the fix is to increase "CONFIG_BT_HCI_TX_STACK_SIZE". What is this currently set to at your end, and could you try to increase this and see if the issue disappears?
The configuration option "CONFIG_BT_HCI_TX_STACK_SIZE" is not directly settable by the user. Based on the configuration in my project, the nRF52840 HCI UART firmware selects a CONFIG_BT_HCI_TX_STACK_SIZE of size 640 and the nRF9160 application firmware selects a CONFIG_BT_HCI_TX_STACK_SIZE of size 512.I was able to manually edit the Kconfig file at zephyr/subsys/bluetooth/host/Kconfig and modify this value for testing purposes to 2048 on both the nRF52840 and nRF9160 side but even with such a large increase I am still seeing the messages in my original post.
There's several changes required in order to get this running properly on v1.3.0 (which we unfortunately haven't updated the patches to), but judging by the log, it seems that you have that sorted out.
Its this that is printing the error on your side: https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/bluetooth/hci/h4.c#L91
There are some inherit drawbacks with this two-chip solution, one is that the host (nrf91) does not have a recovering mechanism if the hci controller (nrf52) resets (where it sends a BT_OP_NOP cmd). It seems like you are able to run for 17 minutes before this occurs. One drawback with the thingy:91 is that you cannot debug both MCUs simultaneously. Have you tried to look at the log from the nRF52840 (enable RTT for logging) to see if it resets mid-sequence?