BLE RX error Unexpected L2CAP continuation

My Nordic device (nRF52833, using SDK 2.1.2) is a peripheral. 
I need to periodically transfer to it large amount of data from central device over connectable Nordic UART Service.
I perform this data transfer in batches of 16 packets, 128 bytes each (due to max payload limitation of 170).
After each batch of 16, peripheral sends XOFF packet, which causes central to wait, so that peripheral can write the data to SPI flash.
After write to flash is complete, peripheral sends XON packet, and transfer resumes.
Very basic flow control.
That works for the most part, but occasionally, Nordic device throws an error   

(15:14:31.168) E: Unexpected L2CAP continuation
(15:14:31.168) E: Unexpected L2CAP continuation
(15:14:31.168) E: Unexpected L2CAP continuation
(15:14:31.287) E: Unexpected L2CAP continuation
(15:14:31.287) E: Unexpected L2CAP continuation


I tried to introduce a small delay between individual packets within batch of 16, but that doesn't solve the problem.

I found an SDK's  Zephyr BT code where this message is printed, but not sure what to make of it

tatic void bt_acl_recv(struct bt_conn *conn, struct net_buf *buf,
uint8_t flags)
{
uint16_t acl_total_len;

/* Check packet boundary flags */
switch (flags) {
case BT_ACL_START:
if (conn->rx) {
BT_ERR("Unexpected first L2CAP frame"); 
bt_conn_reset_rx_state(conn);
}

BT_DBG("First, len %u final %u", buf->len,
(buf->len < sizeof(uint16_t)) ?
0 : sys_get_le16(buf->data));

conn->rx = buf;
break;
case BT_ACL_CONT:
if (!conn->rx) {
BT_ERR("Unexpected L2CAP continuation"); <-----------------
bt_conn_reset_rx_state(conn);
net_buf_unref(buf);
return;
}
1346.config.zip

Would appreciate any insights to what might be causing it and how to avoid it.
My code recovers form this failure on application level, but it affects performance and I'd rather solve it properly

Parents
  • Hello,

    Interesting, I can't find any obvious reason for this. 

    Are you able to provide an on-air sniffer log of when this situation occurs? You can just do a abrupt soft reset when the issue occurs, so it may be easier to know exactly where it occurred. You can for instance use the nRF sniffer for BLE and send us the .pcapng file from Wireshark if possible.

    Btw, does this happen with specific central devices? Can you send us the .config from the build folder also?

    Kenneth

Reply
  • Hello,

    Interesting, I can't find any obvious reason for this. 

    Are you able to provide an on-air sniffer log of when this situation occurs? You can just do a abrupt soft reset when the issue occurs, so it may be easier to know exactly where it occurred. You can for instance use the nRF sniffer for BLE and send us the .pcapng file from Wireshark if possible.

    Btw, does this happen with specific central devices? Can you send us the .config from the build folder also?

    Kenneth

Children
Related