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

  • Hi Kenneth,

    The problem is hard to reproduce so it might be a bit problematic to capture it on sniffer, but I'll try, I do have nRF sniffer (nRF52840 DVK).

    > Btw, does this happen with specific central devices?
    Now that you mentioned it...
    I do have several kinds of devices acting as central (all impplementing same file transfer protocol)
    - Custom board based on Analog Devices Maxim 32690 MCU
    - Mobil phones (all kinds)
    - Seed Studio Xiao BLE device nrf52840 based
    So far, I was able to reproduce the problem with Maxim board only, but that could be because it is the most used...

    Attaching .config

Reply
  • Hi Kenneth,

    The problem is hard to reproduce so it might be a bit problematic to capture it on sniffer, but I'll try, I do have nRF sniffer (nRF52840 DVK).

    > Btw, does this happen with specific central devices?
    Now that you mentioned it...
    I do have several kinds of devices acting as central (all impplementing same file transfer protocol)
    - Custom board based on Analog Devices Maxim 32690 MCU
    - Mobil phones (all kinds)
    - Seed Studio Xiao BLE device nrf52840 based
    So far, I was able to reproduce the problem with Maxim board only, but that could be because it is the most used...

    Attaching .config

Children
Related