• State Not Answered
  • Replies 12 replies
  • Subscribers 88 subscribers
  • Views 1139 views
  • Users 0 members are here
Attachments (4) Download All
Nordic Case Info
  • Case ID: 348516
Options

DFU over BLE using MCUMgr fails with “No available ACL buffers!” and “Unexpected first L2CAP frame” – SDK v2.8.0

Prashant Humbre

Hello Nordic team,

I've recently upgraded my application from nRF Connect SDK v2.7.0 to v2.8.0, and the previous BLE Disconnect issue has been resolved — thanks again for your support!

However, I am now facing a new issue during DFU over BLE using MCUMgr. While DFU via mobile app works fine, using MCUMgr CLI often leads to the following errors:

E: No available ACL buffers!
E: Unexpected first L2CAP frame

These typically appear right after the log: 'Connection parameters updated' During each iteration.

After several iterations, at a random point, the device stops responding and the Disconnect event is not triggered, leading to failed reconnection attempts from MCUMgr.

Key Differences I observed are:

  • Mobile App DFU: Single connection during file transfer.

  • MCUMgr DFU: Multiple rapid connection/disconnection cycles per session.

This issue did not occur with SDK v2.7.0, and only started after migrating to v2.8.0.

I’m following this MCUMgr DFU process:
https://docs.nordicsemi.com/bundle/ncs-3.0.1/page/nrf/app_dev/bootloaders_dfu/dfu_tools_mcumgr_cli.html

Questions:

  1. Are there any changes in buffer handling or controller-side behavior in SDK v2.8.0 that might explain this?

  2. Should I tune CONFIG_BT_BUF_ACL_RX_COUNT, TX_COUNT, or related L2CAP parameters?

  3. Is there a recommended way to handle these frequent connections/disconnections more robustly?

Logs for reference:

Following is one of the log for the reference:
[2025-07-15 18:32:55.416] I: 711689 [SWU]SMP BLE advertising started
[2025-07-15 18:32:55.416] I: 711693 [DL]DFU over SMP started
[2025-07-15 18:33:10.193] I: 726498 [DL]Current number of connections: 1/1
[2025-07-15 18:33:10.215] I: BLE Connected
[2025-07-15 18:33:10.422] I: 726726 [DL]Current number of connections: 0/1
[2025-07-15 18:33:10.438] I: BLE Disconnected: 13
[2025-07-15 18:33:16.322] I: 732607 [DL]Current number of connections: 1/1
[2025-07-15 18:33:16.323] I: BLE Connected
[2025-07-15 18:33:16.546] I: 732837 [DL]DFU Image upload started
[2025-07-15 18:33:17.370] I: Connection parameters updated.
[2025-07-15 18:33:17.370]  interval: 9, latency: 0, timeout: 42
[2025-07-15 18:33:25.985] I: 742273 [DL]Image 0 download completed successfully
[2025-07-15 18:33:26.012] I: 742296 [DL]Current number of connections: 0/1
[2025-07-15 18:33:26.012] I: 742301 [DL]DFU-BLE-Disconnected : 19
[2025-07-15 18:33:26.012] I: BLE Disconnected: 13
[2025-07-15 18:33:38.259] I: 754544 [DL]Current number of connections: 1/1
[2025-07-15 18:33:38.259] I: BLE Connected
[2025-07-15 18:33:38.483] I: 754775 [DL]DFU Image upload started
[2025-07-15 18:33:39.308] I: Connection parameters updated.
[2025-07-15 18:33:39.308]  interval: 9, latency: 0, timeout: 42
[2025-07-15 18:34:20.727] I: 797016 [DL]Image 1 download completed successfully
[2025-07-15 18:34:20.749] I: 797035 [DL]Current number of connections: 0/1
[2025-07-15 18:34:20.750] I: 797039 [DL]DFU-BLE-Disconnected : 19
[2025-07-15 18:34:20.750] I: BLE Disconnected: 13
[2025-07-15 18:34:27.892] I: 804177 [DL]Current number of connections: 1/1
[2025-07-15 18:34:27.892] I: BLE Connected
[2025-07-15 18:34:28.115] I: 804417 [DL]DFU Image upload started
[2025-07-15 18:34:28.957] I: Connection parameters updated.
[2025-07-15 18:34:28.957]  interval: 9, latency: 0, timeout: 42
[2025-07-15 18:34:28.957] E: No available ACL buffers!
[2025-07-15 18:34:28.973] E: Unexpected first L2CAP frame
[2025-07-15 18:38:53.691] I: 1069979 [DL]Image 2 download completed successfully
[2025-07-15 18:38:53.691] I: 1069997 [DL]Current number of connections: 0/1
[2025-07-15 18:38:53.711] I: 1070001 [DL]DFU-BLE-Disconnected : 19
[2025-07-15 18:38:53.711] I: BLE Disconnected: 13
[2025-07-15 18:39:01.356] I: 1077664 [DL]Current number of connections: 1/1
[2025-07-15 18:39:01.372] I: BLE Connected
[2025-07-15 18:39:01.612] I: 1077899 [DL]Current number of connections: 0/1
[2025-07-15 18:39:01.612] I: BLE Disconnected: 13
[2025-07-15 18:39:05.960] I: 1082249 [DL]Current number of connections: 1/1
[2025-07-15 18:39:05.960] I: BLE Connected
[2025-07-15 18:39:06.174] I: 1082463 [DL]DFU_ImgConfirmHandler: Nordic Image Confirmed by MCUMgr
[2025-07-15 18:39:06.190] I: 1082497 [DL]Current number of connections: 0/1
[2025-07-15 18:39:06.206] I: BLE Disconnected: 13
[2025-07-15 18:39:13.392] I: 1089681 [DL]Current number of connections: 1/1
[2025-07-15 18:39:13.392] I: BLE Connected
[2025-07-15 18:39:13.606] I: 1089896 [DL]DFU_ImgConfirmHandler: Nordic Image Confirmed by MCUMgr
[2025-07-15 18:39:13.623] I: 1089929 [DL]Current number of connections: 0/1
[2025-07-15 18:39:13.638] I: BLE Disconnected: 13
[2025-07-15 18:39:21.267] I: 1097576 [DL]Current number of connections: 1/1
[2025-07-15 18:39:21.289] I: BLE Connected
[2025-07-15 18:39:21.576] I: dfu_header_data.image_count: 4
[2025-07-15 18:39:22.341] I: Connection parameters updated.
[2025-07-15 18:39:22.341]  interval: 9, latency: 0, timeout: 42

Best regards,
Prashant

Parents
  • 0

    Hello Prashant,

    The workaround mentioned in the known issue may not be effective because the configuration option CONFIG_BT_BUF_ACL_RX_COUNT_EXTRA was only introduced in NCS version 3.0.0. As a result, I recommend updating to NCS v3.0.0, since there’s no straightforward workaround available for earlier versions.

    For reference, please see this issue: https://github.com/zephyrproject-rtos/zephyr/issues/86091  A related fix was added to the SDC driver here: https://github.com/nrfconnect/sdk-nrf/pull/19869 , this was included in NCS v2.9.0 and later.

    Kind Regards,

    Abhijith

  • 0 in reply to Menon

    Hello Abhijith,

     

    You mentioned that earlier in the thread that you don't think this is specific to the Bluetooth controller, it is more of an nRF Connect SDK issue related to how the Bluetooth Host and Controller manage ACL buffer and timing.

    Our testing indicates the following.

    1) When we update our product (OTA) over BLE using an iOS application we don't see this issue or the ACL error associated with this issue.

    2) When we update our product (OTA) over BLE using a PC with a BLE USB dongle that has a new 5.0 software driver, we don't see this ACL Buffer failure, or the error associated with it.

    3) When we update our product over BLE using a PC with the same BLE USB dongle that has a the original 4.0 driver that, we see an ACL Buffer failure at a frequency of 1 in 10 firmware update cycles, with the 2.8.0 SDK.  With the same dongle and driver we didn't see this failure in the 2.7.0 SDK.

     

    The PC Dongle is used for cycle testing our FW Update(OTA) process, and isn't part of the consumer operating process for our product.  Our question is do you believe that this ACL Buffer error will occur using an iOS or Android device as the Central, or should we expect to only see this issue if the central is doing something unexpected with or over allocating the ACL Buffer mechanism.


    Thanks & regards,

    Prashant H

Reply
  • 0 in reply to Menon

    Hello Abhijith,

     

    You mentioned that earlier in the thread that you don't think this is specific to the Bluetooth controller, it is more of an nRF Connect SDK issue related to how the Bluetooth Host and Controller manage ACL buffer and timing.

    Our testing indicates the following.

    1) When we update our product (OTA) over BLE using an iOS application we don't see this issue or the ACL error associated with this issue.

    2) When we update our product (OTA) over BLE using a PC with a BLE USB dongle that has a new 5.0 software driver, we don't see this ACL Buffer failure, or the error associated with it.

    3) When we update our product over BLE using a PC with the same BLE USB dongle that has a the original 4.0 driver that, we see an ACL Buffer failure at a frequency of 1 in 10 firmware update cycles, with the 2.8.0 SDK.  With the same dongle and driver we didn't see this failure in the 2.7.0 SDK.

     

    The PC Dongle is used for cycle testing our FW Update(OTA) process, and isn't part of the consumer operating process for our product.  Our question is do you believe that this ACL Buffer error will occur using an iOS or Android device as the Central, or should we expect to only see this issue if the central is doing something unexpected with or over allocating the ACL Buffer mechanism.


    Thanks & regards,

    Prashant H

Children
No Data
Related
Terms of service