L2CAP CoC connection only one credit per connection interval

RE: L2CAP CoC connection only one credit per connection interval

Simonr — Thu, 05 Mar 2026 08:47:44 GMT

Hi Paul

I agree we should try finding the root cause here, but checking whether increasing the SDU size helps or not will give us an indicator at least. I tested with the Zephyr Bluetooth shell sample project, where you can connect to BLE devices and initiate L2CAP connections/data transfers with shell commands at need. Attached the build folder below.

devzone.nordicsemi.com/.../6683.build.zip

This is located at the following path if you want to build the application yourself.

...\v3.2.0\zephyr\tests\bluetooth\shell\

There is an overview of how to use the shell here, but bt --help should cover the

Best regards,

Simon

RE: L2CAP CoC connection only one credit per connection interval

PauloM — Wed, 04 Mar 2026 10:58:10 GMT

Hi Simon,

Thank you for uploading the file. It looks similar to what I was seeing, with 3 data packets being sent ever other connection event, but the key difference is that in your case it looks like it is the central that is not responding for 7.3ms not the peripheral. Also it looks like you are sending 10bytes of data per packet, so the time between packets is shorter, so all three data packets complete in ~1.ms, where as mine were taking ~2.5ms per packet

We can try increasing the SDU size, but it feels like this is skirting around an issue without understanding why it is happening. I am still unsure as to why we are only seeing data transmission every other connection event. In theory it should be possible to transmit every connection event.

I actually don't think that increasing the SDU size would help, because we are sending 247bytes payload + 32 bytes of header (247 + 32) x 3 =837Bytes in one event 7.5ms, so 837Bytes x 8bits / 7.5x10-3s = 0.89Mbit/s so we are already at 90% of the theoretical max for the connection events where transmission is actually happening.

Can you share the central code that you used to test with please.

Best regards,

Paul

RE: L2CAP CoC connection only one credit per connection interval

Simonr — Tue, 03 Mar 2026 12:11:18 GMT

Hi again Paul

I'll upload the .pcapng file from my end here again for reference. Some additional context.

We think the absolute easiest thing to do something about here to increase throughput is to increase the SDU sizes. Once a connection event is interrupted because of a conflicting requirement for instance, it can't be resumed and the central must wait until the next connection event.

Spacing the connection events further apart will likely worsen the throughput since the RX/TX pairs are very consistent on our end here.

devzone.nordicsemi.com/.../l2cap_2D00_test_2D00_DKs-_2800_1_2900_.pcapng

Best regards,

Simon

RE: L2CAP CoC connection only one credit per connection interval

PauloM — Tue, 03 Mar 2026 11:28:48 GMT

Hi Simon,

I think I may have been looking at the wrong wireshark file. I cannot see the file that you attached.

Best regards,

Paul

RE: L2CAP CoC connection only one credit per connection interval

Simonr — Tue, 03 Mar 2026 10:14:59 GMT

I don't see any packets having 19.9ms between them in this trace, and you refer to the packets as part of the L2CAP transfer here, right? The 7.3ms between responses are the 7.5 connection interval, and then it sends 3 packets per connection interval from what I can see.

Best regards,

Simon

RE: L2CAP CoC connection only one credit per connection interval

PauloM — Mon, 02 Mar 2026 10:10:43 GMT

Hi Simon,

Good to hear you have it working.

OK noted regarding the MPS.

From the Wireshark log it looks like the same behaviour that I was seeing. If you look at the time difference No 73 (last packet in the interval) and 75 (the response from the server) = 7.3ms. No 84 and 86 = 19.9ms. No 93, 95 = 7.3ms.

If you increase the connection interval this effect becomes even more pronounced, as the time between the last packet in the interval and the response from the server is ~1 connection interval duration.

Best regards,

Paul

RE: L2CAP CoC connection only one credit per connection interval

Simonr — Fri, 27 Feb 2026 07:47:02 GMT

The peripheral seems to be working on our end, and in the sniffer trace the bottleneck seems to be due to the central sending small packets.

The central seems to consistently do 3 RX/TX pairs per connection event, letting it spend ~1.86ms every 7.5ms connection interval.

Note that the peripheral is choosing the L2CAP MPS and MTU to be 247 bytes. This is not optimal. the MPS should be 243 to match the LL data length -4 (for the L2CAP PDU header).

Best regards,

Simon

RE: L2CAP CoC connection only one credit per connection interval

Simonr — Tue, 24 Feb 2026 11:31:26 GMT

Hi again

I've been trying to recreate it on my end, but from my side it seems now like your application reports 12 credits whenever I schedule large packets on mye end. Sniffer trace attached. I've also asked one of the developers for a second opinion on the sniffer trace if they can see something from it, but to me it does seem like the throughput is good, so I'm not sure what else I can do to try recreating this on my end. The L2CAP transfer starts around packet 4830 in this sniffer trace for reference.

devzone.nordicsemi.com/.../l2cap_2D00_test_2D00_DKs.pcapng

RE: L2CAP CoC connection only one credit per connection interval

PauloM — Wed, 18 Feb 2026 10:12:21 GMT

Hi Simon,

OK good news.

Yes we probably should consider migrating at some point. The client does appear to be receiving the initial credits though, we can see this from the wireshark log and the btmon output from the rpi.

This is the python script I was using to test on Rpi 4. It uses the standard socket library. Under the hood I think it talks to the bluez server. Fundamentally I think it just sends data if it has credits to do so, with the caveat that it waits for the server to respond with an ack.

import socket
import struct
import time
import struct
import os

# NOTE: 
# Must use Python 3.14 or higher for L2CAP socket support
# run using: LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/python3.14 l2cap_coc_sock.py


MAC_ADDR = "XX:XX:XX:XX:XX:XX"
PSM = 0x0081                   # L2CAP PSM your NRF52 is listening on (must match peripheral)
CID = 0                        # L2CAP CID 0 means ignore and allow the kernel to choose


def main():
    # Create an L2CAP socket
    with socket.socket(socket.AF_BLUETOOTH, socket.SOCK_SEQPACKET, socket.BTPROTO_L2CAP) as s:
        s.settimeout(5.0)
        s.setblocking(True) 

        print(f"Connecting to {MAC_ADDR} PSM {PSM}...")
        s.connect((MAC_ADDR, PSM, 0, socket.BDADDR_LE_RANDOM))
        print("Connected!")
        # wait for stable connection
        time.sleep(5)

        original_file="my.bin"
        # send data
        PACKET_LENGTH_MAX = 243             # 243 bytes payload + 2 bytes L2CAP header = 245 bytes
        start_time = time.time()
        log_time = start_time
        original_file_size = os.path.getsize(original_file)
        log_counter = 0
        bytes_sent = 0
        with open(original_file, "rb") as f:
            while bytes_sent < original_file_size:
                payload = f.read(PACKET_LENGTH_MAX)
                # Manually pack the 2-byte L2CAP SDU Length header (Little Endian)
                header = struct.pack("<H", len(payload))
                message =  header + payload
                s.send(message)
                bytes_sent += len(payload)
                log_counter += 1
                if log_counter >= 100:
                    bytes_per_log = log_counter * len(payload)
                    duration_per_log = time.time() - log_time
                    duration_total = time.time() - start_time
                    log_time = time.time()
                    line = f'{duration_total:.2f} secs: sent {bytes_sent}B, {float(bytes_per_log)/ float(duration_per_log):.1f} B/sec'
                    print(line)
                    log_counter = 0

if __name__ == "__main__":
    main()

Replicating with an nrf 52dk on the client side makes sense. Just try to spam data and look at the wireshark logs to see if you get the same behaviour I did.

Thank you for your help.

Bes regards,

Paul

RE: L2CAP CoC connection only one credit per connection interval

Simonr — Tue, 17 Feb 2026 15:08:11 GMT

Hi again Paul

Finally some progress on my end. Sorry that it has taken so long. Today I've been able to build and connect to a L2CAP host on my end, but I need some input on how to recreate this from the host on my side. (For reference I'm using another nRF5x DK as the host with the shell sample in Zephyr. Connections and transmissions seem to work successfully, although the L2CAP server doesn't seem to give an acknowledgement it was received. How are the credits handled on the Raspberry Pi side on your end?

Another thing I stumbled upon while going through the code is that init_credits in bt_l2cap_le_endpoint was removed and no longer used as of Zephyr 3.4.0. Since you're on NCS 2.5.0 which uses v3.4.99 of Zephyr I assume that applies to you too, and I've asked the devs how this should be handled in Zephyr 3.4.0 and onwards since the migration guide doesn't really give much info on that. ...\zephyr\doc\releases\migration-guide-3.7.rst

Best regards,

Simon

UPDATE: In NCS 2.5.0, init_credits still exists but is not used anywhere. Instead, using bt_l2cap_chan_give_credits in the accept callback is correct, but that can only be used for channels using _seg_recv cahnnel options.

CONFIG_BT_L2CAP_SEG_RECV} must be enabled to make this function available.

RE: L2CAP CoC connection only one credit per connection interval

PauloM — Fri, 13 Feb 2026 10:35:39 GMT

Hi Simon,

From the header of the west build:

-- west build: generating a build system
-- CMake version: 3.20.5
-- Found Python3: C:/ncs/toolchains/c57af46cb7/opt/bin/python.exe (found suitable version "3.8.2", minimum required is "3.8") found components: Interpreter
-- Zephyr version: 3.4.99
-- Found west (found suitable version "1.1.0", minimum required is "0.14.0")
-- Found host-tools: zephyr 0.16.1 (C:/ncs/toolchains/c57af46cb7/opt/zephyr-sdk)
-- Found toolchain: zephyr 0.16.1 (C:/ncs/toolchains/c57af46cb7/opt/zephyr-sdk)
-- Found Dtc: C:/ncs/toolchains/c57af46cb7/opt/bin/dtc.exe (found suitable version "1.4.7", minimum required is "1.4.6")

Also West version: v1.2.0

We also have our main project building on github workflows using this container.

container:
image: ghcr.io/nrfconnect/sdk-nrf-toolchain:v2.5.0
options: --user=root
env:
ACCEPT_JLINK_LICENSE: 0

Hope this helps

Best regards,

Paul

RE: L2CAP CoC connection only one credit per connection interval

Simonr — Fri, 13 Feb 2026 09:58:30 GMT

I've reached out to a colleague about this as well, but we still haven't been able to build the issue, as there seems to be fundamental toolchain issues when building on our end. Can you share more information about your build environment? What versions of CMake, NCS Toolchain, Zephyr, and west are you using?

Would also be good to hear if you've had some progress with experimenting with buffer sizes on your end.

Best regards,

Simon

RE: L2CAP CoC connection only one credit per connection interval

PauloM — Tue, 10 Feb 2026 09:41:57 GMT

Hi Simon,

I am using VS Code extension, it runs this west command:

west build --build-dir ./l2cap-test/build_lcap_dev ./l2cap-test/application --pristine --board dev_board -- -DNCS_TOOLCHAIN_VERSION="NONE" -DCONFIG_DEBUG_THREAD_INFO=y -DBOARD_ROOT="./l2cap-test/"

Best Regards,

Paul

RE: L2CAP CoC connection only one credit per connection interval

Simonr — Mon, 09 Feb 2026 14:11:49 GMT

Sorry Paul, but I still see the same CMake error messages with this application I'm afraid. Can you show me how you build on your side. Are you using a CLI and west or the Visual Studio Code nRF Connect extension?

Best regards,

Simon

RE: L2CAP CoC connection only one credit per connection interval

PauloM — Thu, 05 Feb 2026 11:35:04 GMT

Hi Simon,

This project builds using nrf connect sdk toolchain 2.5.0. No overlay required, just use the custom dev_board in boards folder and the prj.conf file in application folder.

devzone.nordicsemi.com/.../1374.l2cap_2D00_test.zip

RE: L2CAP CoC connection only one credit per connection interval

Simonr — Wed, 04 Feb 2026 14:05:48 GMT

Hi Paul

I have not been able to build your project yet, no. Nor have I had the time to set up a project using L2CAP credits yet I'm afraid. Sorry about the delays from my end here.

Note that our developers still think this is due to something on the application side not being fast enough, and that is what's leading to buffer starvation and in turn the issues you're seeing. So even if/when I am able reproduce it, experimenting with buffers and completing events is what we'll have to do.

Best regards,

Simon

RE: L2CAP CoC connection only one credit per connection interval

PauloM — Wed, 04 Feb 2026 09:54:09 GMT

Hi Simon,

Oh, Apologies. How are you getting on, do you want me to debug or do you have it building?

RE: L2CAP CoC connection only one credit per connection interval

Simonr — Tue, 03 Feb 2026 10:06:44 GMT

Hi Paul

It seems like a file or build instruction is missing here, as I'm running into various build errors when trying to build your project. I've tried with overlay files and a few variations, but no luck yet.

Nor have I been able to recreate it on my end yet, but I'll keep working on it. Have you made any progress playing around with buffer values on your end?

Best regards,

Simon

RE: L2CAP CoC connection only one credit per connection interval

PauloM — Mon, 02 Feb 2026 10:44:27 GMT

Hi Simon,

Apologies for not getting back sooner.

As I said previously, this project was built on an existing project, so I have had to strip out a lot of code. Hopefully this helps. This project should work with the Nrf 52 DK board. (board called dev_board inside the boards folder)

devzone.nordicsemi.com/.../l2cap_2D00_test.zip

Best regards,

Paul

RE: L2CAP CoC connection only one credit per connection interval

Simonr — Fri, 30 Jan 2026 07:15:51 GMT

Hi Paul

I need to set the expectations straight here. I have been out sick, so I have not been able to work on reproducing this, and will have to resume that on Monday. I'll get back to on Tuesday at the latest with my results. Do you by chance have a project that can reproduce this behavior on a Development Kit to shorten the time it will take for me to get this up and running?

Best regards,

Simon

RE: L2CAP CoC connection only one credit per connection interval

PauloM — Tue, 27 Jan 2026 11:16:28 GMT

Hi Simon,

OK, thank you. I look forward to hearing the result of your testing.

Best Regards,

Paul

RE: L2CAP CoC connection only one credit per connection interval

Simonr — Tue, 27 Jan 2026 09:51:00 GMT

Hi Paul

Right now, we suspect buffer starvation on the SDC side, correct. I'll see if I can reproduce this and experiment with some values later this week. We have created an internal ticket to keep track of this issue on our end now as well. Until we have some progress on our end, all I can recommend is that you play around with buffer values in your application and see if anything helps the throughput.

Best regards,

Simon

RE: L2CAP CoC connection only one credit per connection interval

PauloM — Fri, 23 Jan 2026 12:20:03 GMT

Hi Simon,

I have tried with different connection intervals, and found that by increasing the connection interval I get the expected behaviour. Until the end of the connection interval then a retransmission occurs. But now the retransmission duration is much longer, so the gains that I get from it behaving well initially are largely lost here. Do you think that the SDC is running out of buffer and that is why the nrf is idling for a whole connection interval? Shouldn't the RX buffer be freed after the seg_recv callback? Why would the SDC be running out of buffer? It does not seem to make a difference if I increase CONFIG_BT_CTLR_SDC_RX_PACKET_COUNT.

It looks like this:

t=0 central-> peripheral [CoC, Le information frame] 1
t=2.2ms peripheral-> central [NACK]
t=2.5 central-> peripheral [CoC, Le information frame] 2
t=4.7ms peripheral-> central [NACK]
t=5.0ms central-> peripheral [CoC, Le information frame] 3

...

t=[connection interval] central-> peripheral [CoC, Le information frame]

t=[(connection interval)x2] central-> peripheral [CoC, Le information frame Retransition]

t=[(connection interval)x2 +2ms] peripheral-> central [ACK]

See below for Wireshark logs:

devzone.nordicsemi.com/.../2026_2D00_01_2D00_23_5F00_15ms_5F00_interval_5F00_6credits.pcapng

devzone.nordicsemi.com/.../2026_2D00_01_2D00_23_5F00_30ms_5F00_12cred.pcapng

Best Regards,

Paul

RE: L2CAP CoC connection only one credit per connection interval

PauloM — Fri, 23 Jan 2026 10:51:10 GMT

Hi Simon,

So it is definitely the peripheral side that is slowing things down then.

I tried these config, but no change unfortunately.

CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT=30000

CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT_OVERRIDE=y

Here is my BLE settings from my .config output file, maybe you can see something that I don't

#
# Bluetooth Low Energy
#
CONFIG_BT_MAX_CONN=1
CONFIG_BT_LL_SOFTDEVICE_HEADERS_INCLUDE=y
CONFIG_BT_LL_SOFTDEVICE=y

#
# SoftDevice Controller
#
CONFIG_BT_LL_SOFTDEVICE_BUILD_TYPE_LIB=y
CONFIG_BT_HCI_TX_STACK_SIZE=768
CONFIG_BT_RX_STACK_SIZE=1280
# CONFIG_BT_CTLR_SDC_LLPM is not set
# CONFIG_BT_CTLR_SDC_QOS_CHANNEL_SURVEY is not set
CONFIG_BT_CTLR_SDC_PERIPHERAL_COUNT=1
CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT_OVERRIDE=y
CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT=30000
# CONFIG_BT_CTLR_SDC_PERIODIC_ADV_EVENT_LEN_DEFAULT_OVERRIDE is not set
CONFIG_BT_CTLR_SDC_PERIODIC_ADV_EVENT_LEN_DEFAULT=7500
CONFIG_BT_CTLR_SDC_TX_PACKET_COUNT=12
CONFIG_BT_CTLR_SDC_RX_PACKET_COUNT=12
CONFIG_BT_CTLR_SDC_SCAN_BUFFER_COUNT=3
CONFIG_BT_CTLR_SDC_PERIODIC_SYNC_BUFFER_COUNT=3
CONFIG_BT_CTLR_SDC_RX_PRIO=6
# CONFIG_BT_CTLR_DF is not set
CONFIG_BT_LL_SOFTDEVICE_PERIPHERAL=y
# CONFIG_BT_LL_SOFTDEVICE_MULTIROLE is not set
# CONFIG_BT_LL_SOFTDEVICE_EXPERIMENTAL_ISO is not set
CONFIG_BT_CTLR_FAL_SIZE=8
CONFIG_BT_CTLR_ECDH_LIB_OBERON=y
# CONFIG_BT_CTLR_ECDH_LIB_TINYCRYPT is not set
CONFIG_BT_CTLR_ECDH_STACK_SIZE=900
# CONFIG_BT_CTLR_ECDH_IN_MPSL_WORK is not set
# CONFIG_BT_CTLR_LE_POWER_CONTROL is not set
# end of SoftDevice Controller

#
# BLE Libraries
#
# CONFIG_BT_GATT_POOL is not set
# CONFIG_BT_GATT_DM is not set
# CONFIG_BT_ADV_PROV is not set
# CONFIG_BT_CONN_CTX is not set

#
# Bluetooth Services
#
CONFIG_BT_NRF_SERVICES=y
# CONFIG_BT_AMS_CLIENT is not set
# CONFIG_BT_ANCS_CLIENT is not set
# CONFIG_BT_BAS_CLIENT is not set
# CONFIG_BT_BMS is not set
# CONFIG_BT_CTS_CLIENT is not set
# CONFIG_BT_DFU_SMP is not set
# CONFIG_BT_GATTP is not set
# CONFIG_BT_HIDS is not set
# CONFIG_BT_HOGP is not set
# CONFIG_BT_LBS is not set
# CONFIG_BT_NSMS is not set
CONFIG_BT_NUS=y
# CONFIG_BT_NUS_AUTHEN is not set
# CONFIG_BT_NUS_LOG_LEVEL_OFF is not set
# CONFIG_BT_NUS_LOG_LEVEL_ERR is not set
# CONFIG_BT_NUS_LOG_LEVEL_WRN is not set
# CONFIG_BT_NUS_LOG_LEVEL_INF is not set
# CONFIG_BT_NUS_LOG_LEVEL_DBG is not set
CONFIG_BT_NUS_LOG_LEVEL_DEFAULT=y
CONFIG_BT_NUS_LOG_LEVEL=3
# CONFIG_BT_NUS_CLIENT is not set
# CONFIG_BT_RSCS is not set
# CONFIG_BT_THROUGHPUT is not set
# CONFIG_BT_LATENCY is not set
# CONFIG_BT_LATENCY_CLIENT is not set
# CONFIG_BT_HRS_CLIENT is not set
# CONFIG_BT_DDFS is not set
# CONFIG_BT_MDS is not set
# CONFIG_BT_CGMS is not set
# CONFIG_BT_FAST_PAIR is not set
# CONFIG_BT_DIS is not set
CONFIG_BT_GATT_AUTO_SEC_REQ=y
# end of Bluetooth Services

#
# BLE over nRF RPC
#
# CONFIG_BT_RPC is not set
# CONFIG_BT_RPC_STACK is not set
# CONFIG_BT_CENTRAL is not set
CONFIG_BT_PERIPHERAL=y
# CONFIG_BT_OBSERVER is not set
CONFIG_BT_BROADCASTER=y
CONFIG_BT_CONN=y
# CONFIG_BT_REMOTE_VERSION is not set
# CONFIG_BT_PHY_UPDATE is not set
CONFIG_BT_DATA_LEN_UPDATE=y
# CONFIG_BT_EXT_ADV is not set
# CONFIG_BT_BAS is not set
# CONFIG_BT_HRS is not set
# CONFIG_BT_TPS is not set
# CONFIG_BT_IAS is not set
# CONFIG_BT_IAS_CLIENT is not set
# CONFIG_BT_OTS is not set
# CONFIG_BT_OTS_CLIENT is not set
CONFIG_BT_BUF_ACL_TX_COUNT=12
CONFIG_BT_BUF_ACL_RX_COUNT=12
CONFIG_BT_BUF_EVT_RX_SIZE=68
CONFIG_BT_BUF_EVT_RX_COUNT=12
CONFIG_BT_BUF_EVT_DISCARDABLE_SIZE=43
CONFIG_BT_BUF_EVT_DISCARDABLE_COUNT=6
CONFIG_BT_BUF_CMD_TX_SIZE=65
CONFIG_BT_HAS_HCI_VS=y
CONFIG_BT_HCI_VS=y
# CONFIG_BT_WAIT_NOP is not set
CONFIG_BT_RPA=y
# CONFIG_BT_ASSERT is not set
CONFIG_BT_DEBUG_NONE=y
# CONFIG_BT_DEBUG_LOG is not set
# CONFIG_BT_DEBUG_MONITOR_UART is not set
# CONFIG_BT_DEBUG_MONITOR_RTT is not set
# CONFIG_BT_LONG_WQ is not set
CONFIG_BT_HCI_HOST=y
CONFIG_BT_HCI_TX_STACK_SIZE_WITH_PROMPT=y
CONFIG_BT_HCI_TX_PRIO=7
CONFIG_BT_HCI_RESERVE=0
# CONFIG_BT_RECV_BLOCKING is not set
# CONFIG_BT_RECV_WORKQ_SYS is not set
CONFIG_BT_RECV_WORKQ_BT=y
CONFIG_BT_RX_PRIO=8
CONFIG_BT_DRIVER_RX_HIGH_PRIO=6
# CONFIG_BT_AUDIO is not set
CONFIG_BT_SETTINGS=y
CONFIG_BT_SETTINGS_CCC_LAZY_LOADING=y
CONFIG_BT_SETTINGS_DELAYED_STORE=y
CONFIG_BT_SETTINGS_DELAYED_STORE_MS=1000
CONFIG_BT_SETTINGS_CCC_STORE_ON_WRITE=y
CONFIG_BT_SETTINGS_USE_PRINTK=y
# CONFIG_BT_FILTER_ACCEPT_LIST is not set
CONFIG_BT_LIM_ADV_TIMEOUT=30
CONFIG_BT_CONN_TX_USER_DATA_SIZE=8
CONFIG_BT_CONN_TX_MAX=12
# CONFIG_BT_CONN_PARAM_ANY is not set
# CONFIG_BT_USER_DATA_LEN_UPDATE is not set
CONFIG_BT_AUTO_DATA_LEN_UPDATE=y
# CONFIG_BT_REMOTE_INFO is not set
CONFIG_BT_SMP=y
# CONFIG_BT_PASSKEY_KEYPRESS is not set
# CONFIG_BT_PRIVACY is not set
# CONFIG_BT_SIGNING is not set
# CONFIG_BT_SMP_APP_PAIRING_ACCEPT is not set
# CONFIG_BT_SMP_SC_PAIR_ONLY is not set
# CONFIG_BT_SMP_SC_ONLY is not set
# CONFIG_BT_SMP_OOB_LEGACY_PAIR_ONLY is not set
# CONFIG_BT_SMP_DISABLE_LEGACY_JW_PASSKEY is not set
# CONFIG_BT_SMP_ALLOW_UNAUTH_OVERWRITE is not set
# CONFIG_BT_ID_UNPAIR_MATCHING_BONDS is not set
# CONFIG_BT_ID_ALLOW_UNAUTH_OVERWRITE is not set
# CONFIG_BT_FIXED_PASSKEY is not set
# CONFIG_BT_USE_DEBUG_KEYS is not set
# CONFIG_BT_BONDABLE is not set
# CONFIG_BT_BONDABLE_PER_CONNECTION is not set
# CONFIG_BT_STORE_DEBUG_KEYS is not set
CONFIG_BT_SMP_ENFORCE_MITM=y
# CONFIG_BT_KEYS_OVERWRITE_OLDEST is not set
CONFIG_BT_SMP_MIN_ENC_KEY_SIZE=7
CONFIG_BT_L2CAP_TX_BUF_COUNT=12
CONFIG_BT_L2CAP_TX_FRAG_COUNT=2
CONFIG_BT_L2CAP_RESCHED_MS=1000
CONFIG_BT_L2CAP_DYNAMIC_CHANNEL=y
# CONFIG_BT_L2CAP_ECRED is not set
CONFIG_BT_L2CAP_SEG_RECV=y
CONFIG_BT_ATT_ENFORCE_FLOW=y
CONFIG_BT_ATT_PREPARE_COUNT=0
CONFIG_BT_ATT_RETRY_ON_SEC_ERR=y
CONFIG_BT_GATT_AUTO_RESUBSCRIBE=y
# CONFIG_BT_GATT_SERVICE_CHANGED is not set
CONFIG_BT_GATT_ENFORCE_SUBSCRIPTION=y
CONFIG_BT_GATT_CLIENT=y
CONFIG_BT_GATT_READ_MULTIPLE=y
CONFIG_BT_GATT_READ_MULT_VAR_LEN=y
# CONFIG_BT_GATT_AUTO_DISCOVER_CCC is not set
# CONFIG_BT_GATT_AUTO_UPDATE_MTU is not set
CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=y
# CONFIG_BT_GAP_PERIPHERAL_PREF_PARAMS is not set
CONFIG_BT_DEVICE_NAME_GATT_WRITABLE=y
CONFIG_DEVICE_NAME_GATT_WRITABLE_ENCRYPT=y
# CONFIG_DEVICE_NAME_GATT_WRITABLE_AUTHEN is not set
CONFIG_BT_MAX_PAIRED=1
CONFIG_BT_CREATE_CONN_TIMEOUT=3
CONFIG_BT_CONN_PARAM_UPDATE_TIMEOUT=5000
CONFIG_BT_CONN_PARAM_RETRY_COUNT=3
CONFIG_BT_CONN_PARAM_RETRY_TIMEOUT=5000
CONFIG_BT_DEVICE_NAME_DYNAMIC=y
CONFIG_BT_DEVICE_NAME_MAX=10
CONFIG_BT_DEVICE_NAME="SX"
# CONFIG_BT_DEVICE_APPEARANCE_DYNAMIC is not set
CONFIG_BT_DEVICE_APPEARANCE=0
CONFIG_BT_ID_MAX=1
CONFIG_BT_ECC=y
# CONFIG_BT_TINYCRYPT_ECC is not set
# CONFIG_BT_HOST_CCM is not set
# CONFIG_BT_LOG_SNIFFER_INFO is not set
# CONFIG_BT_TESTING is not set
# CONFIG_BT_BREDR is not set
# CONFIG_BT_HCI_VS_EVT_USER is not set
CONFIG_BT_CRYPTO=y
# end of BLE over nRF RPC
# end of Bluetooth Low Energy

Best regards,

Paul

RE: L2CAP CoC connection only one credit per connection interval

Simonr — Fri, 23 Jan 2026 07:04:50 GMT

The C2P packets labeled as retransmissions without a preceding NACK is expected since the SoftDevice controller stays silent when it runs out of RX buffers in order to make the Central wait until the next connection event.

You can try increasing CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT in your prj.conf as well as enabling the BT_CTLR_SDC_CONN_EVENT_EXTEND_DEFAULT config to allow for the controller to extend the connection event as much as possible if peers have more data to send and there are no conflicts with other roles of the same/higher priority.

Best regards,

Simon