BT_HCI_ERR_CONN_LIMIT_EXCEEDED when writing to a characteristic

[esisk]

Using NCS 1.7.0 with a an nRf9160/nRF52820 split Host/Controller as a peripheral and an nRF52840 as a central. I can connect to the peripheral with my central fine and write to a custom service I created. I'm getting an error 9 in my bt_gatt_write_func_t callback which translates to BT_HCI_ERR_CONN_LIMIT_EXCEEDED when I try to write to another one of my custom services during the lifecycle of the connection. I'm a little confused by the error code because it seems to have to do with how many connections the central can have but I'm already connected. Is there a limit to how many services a central can write to during a connection? I can write/read characteristics in the first service I have, and I can read characteristics of the second but can't write to the second.

[Simon]

Try to increase BT_ATT_PREPARE_COUNT. Check in <sample>/build/zephyr/.config what it's already set to and try to increase it to a higher value.

---

Explanation:

I think an error 9 coming from bt_gatt_write_func_t corresponds to BT_ATT_ERR_PREPARE_QUEUE_FULL, you can see in the explanatory text that it returns an att error. In zephyr/subsys/bluetooth/host/att.c I could see that this error happens in this case: https://github.com/nrfconnect/sdk-zephyr/blob/731d4be8bb86159cbe48ea19998ba7451e70cef9/subsys/bluetooth/host/att.c#L2055, so increasing CONFIG_BT_ATT_PREPARE_COUNT might resolve the issue (see https://github.com/nrfconnect/sdk-zephyr/blob/731d4be8bb86159cbe48ea19998ba7451e70cef9/subsys/bluetooth/host/att.c#L65-L66 ).

Best regards,

Simon

[esisk]

Hey Simon,

Yep, yesterday I discovered that error code and figured it was more likely to be what was wrong since I was attempting to perform a write with len=2048 bytes. I tried to increase CONFIG_BT_ATT_PREPARE_COUNT from 2 to 10 in order to fix it but I may need an even bigger value. Thanks for the help and linking the GitHub issue, I'll keep you updated with my progress

Edit: So I increased CONFIG_BT_ATT_PREPARE_COUNT all the way to its max value of 64 and I'm still getting the same error. Is there some sort of maximum length that a write can be? I also put a print statement in the case (https://github.com/nrfconnect/sdk-zephyr/blob/731d4be8bb86159cbe48ea19998ba7451e70cef9/subsys/bluetooth/host/att.c#L2055) but I didn't see anything in the console

[Simon]

Could you try to do some debugging?

Could you set a break point inside the bt_gatt_write_func_t function when the error happens and upload an image of the call stack, then I can see where the error comes from and hopefully figure out the cause.

You could also try to enable some more logs:

CONFIG_LOG=y
CONFIG_BT_DEBUG_ATT=y
CONFIG_BT_DEBUG_GATT=y

That may give you some more information of why it's failing.

Best regards,

Simon

[esisk]

I'll set the breakpoint and try to figure it out. I typically don't have luck with the VS Code debugger. Also, whenever I enabled BT logging, what is printed out to the terminal is uninterpretable; I just get tons of dropped messages. I use RTT Viewer. I'll try to figure out a way to get the prints to be a bit more readable

Edit: Got everything to work. Here's a log

00> [00:01:41.859,100] <dbg> bt_att.bt_att_req_alloc: req 0x2003efd4
00> [00:01:41.859,130] <dbg> bt_att.bt_att_req_send: conn 0x200029b8 req 0x2003efd4
00> [00:01:41.859,161] <dbg> bt_att.att_req_send_process: req 0x2003efd4
00> [00:01:41.859,161] <dbg> bt_att.bt_att_chan_req_send: req 0x2003efd4
00> [00:01:41.859,161] <dbg> bt_att.chan_req_send: chan 0x200395a0 req 0x2003efd4 len 96
00> [00:01:41.859,161] <dbg> bt_att.chan_send: code 0x16
00> [00:01:41.878,326] <dbg> bt_att.att_req_sent: conn 0x200029b8 chan 0x200395a0
00> [00:01:41.878,326] <dbg> bt_att.att_sent: conn 0x200029b8 chan 0x200395a8
00> [00:01:41.878,356] <dbg> bt_att.bt_att_sent: chan 0x200395a0
00> [00:01:41.878,356] <dbg> bt_att.chan_req_sent: chan 0x200395a0 chan->req 0x2003efd4
00> [00:01:41.907,897] <dbg> bt_att.bt_att_recv: Received ATT chan 0x200395a0 code 0x17 len 95
00> [00:01:41.907,928] <dbg> bt_att.att_handle_prepare_write_rsp: 
00> [00:01:41.907,989] <dbg> bt_att.att_handle_rsp: chan 0x200395a0 err 0x00 len 95: 1a0000000fb10700000000000008000002000078ae07000000000000000000000~
00> [00:01:41.907,989] <dbg> bt_att.bt_att_req_free: req 0x2003efd4
00> [00:01:41.907,989] <dbg> bt_gatt.gatt_prepare_write_rsp: err 0x00
00> [00:01:41.908,020] <dbg> bt_att.bt_att_req_alloc: req 0x2003efd4
00> [00:01:41.908,081] <dbg> bt_att.bt_att_req_send: conn 0x200029b8 req 0x2003efd4
00> [00:01:41.908,081] <dbg> bt_att.att_req_send_process: req 0x2003efd4
00> [00:01:41.908,081] <dbg> bt_att.bt_att_chan_req_send: req 0x2003efd4
00> [00:01:41.908,081] <dbg> bt_att.chan_req_send: chan 0x200395a0 req 0x2003efd4 len 96
00> [00:01:41.908,111] <dbg> bt_att.chan_send: code 0x16
00> [00:01:41.915,435] <dbg> bt_att.att_req_sent: conn 0x200029b8 chan 0x200395a0
00> [00:01:41.915,435] <dbg> bt_att.att_sent: conn 0x200029b8 chan 0x200395a8
00> [00:01:41.915,435] <dbg> bt_att.bt_att_sent: chan 0x200395a0
00> [00:01:41.915,435] <dbg> bt_att.chan_req_sent: chan 0x200395a0 chan->req 0x2003efd4
00> [00:01:41.945,404] <dbg> bt_att.bt_att_recv: Received ATT chan 0x200395a0 code 0x17 len 95
00> [00:01:41.945,434] <dbg> bt_att.att_handle_prepare_write_rsp: 
00> [00:01:41.945,495] <dbg> bt_att.att_handle_rsp: chan 0x200395a0 err 0x00 len 95: 1a005b00fffffffffffffffffffffffffffffffffffffffffffffffffffffffff~
00> [00:01:41.945,495] <dbg> bt_att.bt_att_req_free: req 0x2003efd4
00> [00:01:41.945,526] <dbg> bt_gatt.gatt_prepare_write_rsp: err 0x00
00> [00:01:41.945,556] <dbg> bt_att.bt_att_req_alloc: req 0x2003efd4
00> [00:01:41.945,587] <dbg> bt_att.bt_att_req_send: conn 0x200029b8 req 0x2003efd4
00> [00:01:41.945,587] <dbg> bt_att.att_req_send_process: req 0x2003efd4
00> [00:01:41.945,587] <dbg> bt_att.bt_att_chan_req_send: req 0x2003efd4
00> [00:01:41.945,587] <dbg> bt_att.chan_req_send: chan 0x200395a0 req 0x2003efd4 len 96
00> [00:01:41.945,617] <dbg> bt_att.chan_send: code 0x16
00> [00:01:41.952,941] <dbg> bt_att.att_req_sent: conn 0x200029b8 chan 0x200395a0
00> [00:01:41.952,972] <dbg> bt_att.att_sent: conn 0x200029b8 chan 0x200395a8
00> [00:01:41.952,972] <dbg> bt_att.bt_att_sent: chan 0x200395a0
00> [00:01:41.952,972] <dbg> bt_att.chan_req_sent: chan 0x200395a0 chan->req 0x2003efd4
00> [00:01:41.973,815] <dbg> bt_att.bt_att_recv: Received ATT chan 0x200395a0 code 0x01 len 4
00> [00:01:41.973,846] <dbg> bt_att.att_error_rsp: request 0x16 handle 0x001a error 0x09
00> [00:01:41.973,876] <dbg> bt_att.att_handle_rsp: chan 0x200395a0 err 0x09 len 0: 
00> [00:01:41.973,876] <dbg> bt_att.bt_att_req_free: req 0x2003efd4
00> [00:01:41.973,907] <dbg> bt_gatt.gatt_prepare_write_rsp: err 0x09

and here's a screenshot of the call stack:

I have a little more to work with, it seems as if it prepares two writes successfully then fails on the third