bt_sdc_hci_driver: No data buffer available

Hi, 

I have a field application with a gateway (central) that connects to multiple peripherals for continuous data streaming, in this case 10 peripherals. I notice sometimes the gateway 'stops reporting data' and today I was able to connect a JLINK to read out the logs of the nRF52840 that's taking care of the BLE connectivity and I saw "bt_sdc_hci_driver: No data buffer available" being printed out all the time, which seems to be implemented in hci_driver.c in data_packet_process. It's pretty random how long it takes for the gateway to become non-responsive, I've seen it happen after less than an hour, now it happened after almost a week of normal operation. I followed the code in hci_driver.c and it seems the data buffer is allocated from CONFIG_BT_BUF_EVT_RX_COUNT, which I had set at 20. What could be the reason that 20 buf_count is not sufficient when connecting to 10 peripherals? The connection interval is 125ms for all the peripherals. As far as I can tell, I'm not doing any long processing when data comes in. Are there any other configs I can play around with (or increase CONFIG_BT_BUF_EVT_RX_COUNT to provide more margin), or should I focus on checking how long my code takes when receiving data or if there is anything that could be blocking?

Best,

Wout

Parents Reply Children
  • Thanks for the feedback Einar. I'm currently away so I cannot make the changes, but I will do so next week when I'm back. I don't use ISO channels indeed.

    Can you give some more context as to why CONFIG_BT_BUF_ACL_RX_COUNT_EXTRA may help? I don't have it set currently and looking at the .config file in my output, it's not set by default. I do see that CONFIG_BT_BUF_ACL_RX_COUNT is set to the default of only 6, so it is probably good to increase this to a significantly higher number than CONFIG_BT_MAX_CONN to ensure there are sufficient buffers available for incoming data. But how do the ACL_RX_COUNT_EXTRA buffers come into play?

  • Hi,

    CONFIG_BT_BUF_ACL_RX_COUNT is deprecated and CONFIG_BT_BUF_ACL_RX_COUNT_EXTRA is used instead ot incrase the ACL RX buffer count. If using an older SDK (?), you should incrase CONFIG_BT_BUF_ACL_RX_COUNT instead.

    This incrases the ACL RX (in) buffer count, and the error is caused by no available buffers. It is possible that the root cause is something else, but I would try this first.

  • Thanks Einar! Just in case others stumble on this post: I found that CONFIG_BT_BUF_ACL_RX_COUNT_EXTRA is introduced in Zephyr v4.1.0. The amount of ACL buf counts is from then on calculated as CONFIG_BT_MAX_CONN +1. That's why the config symbol is renamed to CONFIG_BT_BUF_ACL_RX_COUNT_EXTRA to allow adding extra buffers on top of the default calculated amount. I'm currently still at ncs v2.5.0 which is on Zephyr v3.4.99, so I'll just manually set my CONFIG_BT_BUF_ACL_RX_COUNT to match CONFIG_BT_MAX_CONN + 1.

Related