BLE ATT notification can-send callback gets stuck after reconnect on Raspberry Pi Pico W / CYW43

[savejeff]

Hi. I think i found a Bug with Pico W (2) BLE Notify. it seems the connection state is not fully cleared/reset and causes later connections to break.
im using att_server_register_can_send_now_callback to send notify packages. after disconnect and reconnect these callbacks start to not be called back.

disclaimer: as my left arm is currently in a cast, i had to use Codex to write the issue report.

here also a repo that demonstrates the issue reliably on the second connect: Demo
the Demo also explains how to reproduce the issue

Summary

On Raspberry Pi Pico W / Pico 2 W using BTstack through the Arduino-Pico core, ATT notification transmission can reliably stall after a BLE reconnect.

The failure appears around att_server_register_can_send_now_callback(). On the first connection, the callback is usually called immediately from inside att_server_register_can_send_now_callback() when ACL send credit is available. On the second connection, after a small number of successful notifications, one registration no longer invokes the callback immediately and the callback is never delivered later. All following calls to att_server_register_can_send_now_callback() return ERROR_CODE_COMMAND_DISALLOWED (0x0c, rc=12), suggesting that the callback registration remains queued in att_server->notification_requests.

This is highly reproducible.

Environment

Hardware:

• Raspberry Pi Pico W / Pico 2 W
• CYW43 Bluetooth controller

Software:

• PlatformIO
• Arduino-Pico core
• BTstack from Arduino-Pico / Pico SDK package

Observed with:

• platform-raspberrypi 1.20.0+sha.aa70b80 (latest)
• framework-arduinopico 1.50601.0+sha.832f2c06 (latest)
• BTstack dependency reported as BTstack @ 1.0

The same behavior was also observed on an older Arduino-Pico core before updating.

Reproducer Shape

The firmware exposes a simple Nordic-UART-like GATT service:

• TX characteristic: notify
• RX characteristic: write / write without response (optional)

The peripheral sends dummy notification data only through the ATT can-send callback path:

att_server_register_can_send_now_callback(&tx_ready_callback_registration, connection_handle);

When the callback fires, the firmware sends exactly one notification:

att_server_notify(connection_handle, notify_char_handle, payload, payload_len);

Then it re-arms later from the main loop, not recursively from inside the callback.

The test traffic is intentionally modest:

• Requested ATT MTU: 517
• Max notification payload: 514 bytes
• Offered notification payload rate: about 1000 B/s
• Pending TX debt capped to one ATT payload
• One notification per can-send callback

So this is not an unbounded notification flood.

Reliable Trigger

1. Start advertising.
2. Connect from a BLE central.
3. Enable notifications on the TX characteristic.
4. Send notifications using att_server_register_can_send_now_callback() / att_server_notify().
5. Disconnect from the central.
6. Reconnect from the central.
7. Enable notifications again.
8. Continue the same notification flow.

On the second connection, the bug occurs consistently after a few successful sends.

Typical observed sequence:

cycle 1:
  connect
  MTU exchange
  notifications enabled
  notification stream works
  central disconnects
  firmware receives notify disabled
  firmware receives device disconnected / ATT disconnected

cycle 2:
  reconnect
  MTU exchange
  notifications enabled
  first few notifications work
  then can-send callback registration stops producing a callback
  every later registration returns rc=12
  no more notifications
  firmware remains in stale conn=1/sub=1 state
  later reconnect attempts time out

Example log excerpt:

device: connected #2, handle=0x0040
mtu: notify_payload=514, requested_by_test=517
notify: enabled

... first few notifications succeed ...

tx: ready_request_failed rc=12, pending=514

status: conn=1, sub=1, handle=0x0040, payload=514,
        pending=514, ready_pending=0, ready_events=4,
        sent_bytes=1572, sent_packets=4,
        failures=0, ready_failures=10

tx: ready_request_failed rc=12, pending=514
tx: ready_request_failed rc=12, pending=514
...

After this point, ready_failures keeps increasing. No later ATT_EVENT_DISCONNECTED / device disconnected event is observed for the stalled connection.

Observed Callback Behavior

On the first connection, att_server_register_can_send_now_callback() often calls the registered callback synchronously before returning.

The path appears to be:

att_server_register_can_send_now_callback()
  -> att_server_request_to_send_notification()
    -> btstack_linked_list_add_tail(&att_server->notification_requests, callback)
    -> att_server_request_can_send_now()
      -> att_dispatch_server_request_can_send_now_event()
        -> l2cap_request_can_send_fix_channel_now_event()
          -> l2cap_notify_channel_can_send()
            -> l2cap_channel_ready_to_send()
            -> l2cap_channel_trigger_send()
              -> L2CAP_EVENT_CAN_SEND_NOW
                -> att_server_handle_can_send_now()
                  -> remove callback from notification_requests
                  -> callback()

That immediate callback behavior seems expected when LE ACL send credit is available.

After reconnect, the first few notifications still work. Then one registration appears to be queued but not delivered:

att_server_register_can_send_now_callback()
  -> callback is added to notification_requests
  -> no immediate callback, presumably no ACL credit at that instant
  -> expected later L2CAP_EVENT_CAN_SEND_NOW never arrives
  -> callback remains queued
  -> next registration with same callback object returns rc=12

rc=12 is ERROR_CODE_COMMAND_DISALLOWED. In att_server_request_to_send_notification(), this appears to happen when btstack_linked_list_add_tail() refuses to add the same callback object because it is already present in att_server->notification_requests.

Suspected Cause

The initial failure is probably not rc=12 itself. rc=12 looks like the aftermath.

The suspected root issue is that after reconnect, a queued ATT notification can-send request is not later released by the expected L2CAP/HCI can-send path.

Possible causes:

1. HCI completed-packets / ACL credit recovery is missing or ignored

   • hci_can_send_acl_le_packet_now() becomes false after a few sends.
   • BTstack queues the notification callback.
   • The expected HCI_EVENT_NUMBER_OF_COMPLETED_PACKETS or equivalent event does not drive L2CAP again.
   • The queued callback remains stuck.

2. L2CAP fixed-channel can-send state gets stuck

   • l2cap_request_can_send_fix_channel_now_event() sets fixed ATT channel waiting state.
   • The later l2cap_notify_channel_can_send() path does not emit L2CAP_EVENT_CAN_SEND_NOW.

3. ATT dispatch global pending state becomes inconsistent after reconnect

   • For fixed ATT, att_dispatch.c uses global waiting/pending state.
   • After reconnect, this state may prevent another can-send event from being requested or delivered.

4. Stale ATT notification request survives in current connection state

   • The callback remains in att_server->notification_requests.
   • Subsequent registration attempts fail with ERROR_CODE_COMMAND_DISALLOWED.

Connection Handle Note

The connection handle is always 0x0040 in the logs. This appears to be assigned by the controller in the HCI LE Connection Complete event and simply stored by BTstack.

Repeated 0x0040 after a clean disconnect is probably valid controller behavior, since HCI connection handles only need to be unique among active connections.

However, the repeated handle makes it important to confirm that all per-connection ATT/L2CAP/HCI state is fully reset on disconnect/reconnect.

Expected Behavior

If att_server_register_can_send_now_callback() successfully queues a callback and the connection remains valid, BTstack should eventually invoke the callback once ACL send credit becomes available.

If the connection is disconnected before the callback can be invoked, the queued request should be cleaned up as part of connection teardown, and later reconnects should not inherit stale notification request state.

Actual Behavior

After reconnect:

• att_server_register_can_send_now_callback() succeeds a few times.
• Then one callback registration remains queued.
• The callback is never invoked.
• Further registration attempts return ERROR_CODE_COMMAND_DISALLOWED (rc=12).
• No more notifications are sent.
• Firmware continues to report connected/subscribed state.
• Later central reconnect attempts time out.

Minimal Reproducer

I have a reduced single-file repro that uses direct Arduino-Pico / BTstack calls. It creates a simple notify/write GATT service and drives notifications only through the ATT can-send callback mechanism.

I can provide the complete repro and logs if useful.

[mringwal]

Hi. Thanks for detailed (most likely) AI-generated report and reproducer.

Could you provide an HCI PacketLog in addition / instead?
I think you can uncomment "WANT_HCI_DUMP" somewhere in the pico-sdk.

As for the issue, it looks like the list of registered callbacks is not cleared, which would explain why a few notifications can be sent (right now, the HCI Transport is synchronous which allows to forward a few packets immediately). We'll have a detailed look soon.

Best regards,
Matthias

[savejeff]

Hi Matthias,
yes as i can currently only type with one hand, i had to ask AI to summarize my results.
here its result for the packetlogs:

---

I captured a new repro run with HCI PacketLog enabled and will attach the generated files.

The capture was done on a Raspberry Pi Pico W / RP2040 using the Arduino-Pico core with BTstack debug output enabled through:

-D DEBUG_RP2040_PORT=Serial
-D DEBUG_RP2040_BLUETOOTH

The test performs two BLE connection cycles with a 5 s delay between disconnect and reconnect.

Traffic generated by the firmware:

• Peripheral advertises as BLEDemo
• Central connects, negotiates MTU 517
• Central subscribes to the notify characteristic
• Firmware sends one notification only after att_server_register_can_send_now_callback() reports readiness via the can-send-now callback
• Payload length in this run: 250 bytes per notification
• Intended traffic rate: 1000 B/s
• No busy-loop notification sending is used

Observed result from this run:

First connection:

• Connect succeeds
• MTU exchange succeeds
• Notify subscription succeeds
• 45 notifications are received correctly
• Disconnect is clean

Second connection:

• Reconnect succeeds with the same HCI connection handle 0x0040
• MTU exchange succeeds
• Notify subscription succeeds
• 4 notifications are sent successfully
• The next can-send-now registration returns success but does not invoke the callback immediately or later
• After the firmware timeout, subsequent registrations return rc=12 (ERROR_CODE_COMMAND_DISALLOWED)
• No further notifications are delivered

Relevant firmware log excerpt from the attached hci_packetlog_20260711_125137.txt:

[39690] device: connected_nr=2, handle=0x0040
[39964] notify: subscribed=1

[40939] tx.tx_ready: id=1, dt_callback=0, pending_bytes=250
[40955] tx.rqst: id=1, res=0, pending=0

[41189] tx.tx_ready: id=2, dt_callback=0, pending_bytes=250
[41205] tx.rqst: id=2, res=0, pending=0

[41439] tx.tx_ready: id=3, dt_callback=0, pending_bytes=250
[41455] tx.rqst: id=3, res=0, pending=0

[41689] tx.tx_ready: id=4, dt_callback=0, pending_bytes=250
[41705] tx.rqst: id=4, res=0, pending=0

[41939] tx.rqst: id=5, res=0, pending=1
[42439] tx.rqst: warn='tx rqst timeout' age_last_rqst=500
[42439] tx: err='ready_request_failed', rc=12, pending=514
[42439] tx.rqst: id=6, res=12, pending=0

Later status shows the stuck state:

status: conn=1, sub=1, handle=0x0040, payload=514,
pending_bytes=514, is_tx_rqst_pending=0,
ready_events=4, ready_events_direct=4,
sent_bytes=1000, sent_packets=4,
blocked=1, failures=0, ready_failures=...

The HCI log contains real CMD =>, EVT <=, ACL =>, and ACL <= records. The converted PacketLogger file is attached as:

• hci_packetlog_20260711_125137.pklg

I will also attach:

• hci_packetlog_20260711_125137.txt
• ble_capture_20260711_125137.jsonl

The BLE-side capture confirms that the first connection receives 45 notifications, while the second connection receives only 2 notifications before the peripheral stops producing notifications.

hci_packetlog_20260711_125137.txt

ble_capture_20260711_125137.jsonl.txt

hci_packetlog_20260711_125137.zip

[savejeff]

this might be relevant

IoT-gamer/pico-ble-notify#1 (comment)

During testing, I was able to get the queue to process payloads larger than 255 bytes initially. However, it exposed two major roadblocks:

The Reconnection Queue Jam: When a client disconnects and reconnects, the BLE specification mandates that the MTU resets back to the default 23 bytes. If the client tries to re-subscribe and send a large payload before negotiating the new MTU, the BTstack radio rejects the packet, permanently jamming the notification queue.

The Upstream Arduino Core Limit: Even after writing safeguards to prevent the queue jam, I hit a hard limit in the Arduino-Pico core's pre-compiled BTstack configuration. The core has its internal ATT buffers hardcoded to smaller defaults to save RAM. When a client (like nRF Connect) requests a large MTU (e.g., 517), the Arduino core's BTstack automatically forces it back down, keeping the actual over-the-air payload strictly limited.

[savejeff]

ive run some tests to investigate at what package size the issue occurs. ive found that its stable with 244 bytes but not for 245.
here what the ai had to say about it:

---

The payload threshold we found earlier is very meaningful:

244 B notification payload: stable
245 B notification payload: fails in Arduino-Pico repro
That boundary matches BLE packet sizing exactly:
ATT notification payload      N bytes
ATT notification header       3 bytes
L2CAP header                  4 bytes
-------------------------------------
Controller/L2CAP data total   N + 7 bytes

So:

244 + 7 = 251 bytes
245 + 7 = 252 bytes

251 bytes is the common LE Data Length maximum. So the Arduino failure starts exactly when one notification no longer fits into a single 251-byte link-layer data packet and must be fragmented.
That strongly points at fragmentation / ACL credit / completed-packet handling after reconnect, not at MTU negotiation or your application queue.

[savejeff]

Ive also ported the notify code to a pico sdk project. here the bug/issue does not occur.
here the AIs conclusion:

---

The pure SDK version does not reproduce because the native BTstack/CYW43 run loop handles the post-reconnect fragmented notification path correctly.
The Arduino-Pico version fails when notifications exceed 244 bytes, meaning the packet crosses the 251-byte controller data boundary and requires fragmentation. After reconnect, one can-send callback registration remains pending, but the expected lower-layer completion/can-send chain never comes back. That suggests stale or lost state in the Arduino-Pico BTstack/CYW43 async integration, especially around ACL buffer credits or completed-packet processing.
So the current best narrowed statement is:

The bug is not caused by large MTU alone. It appears when a notification payload exceeds 244 bytes, causing the ATT notification plus ATT/L2CAP headers to exceed 251 bytes and require lower-layer fragmentation. The failure only appears in the Arduino-Pico integration, not in the pure Pico SDK implementation, making the Arduino-Pico BTstack/CYW43 run-loop or ACL flow-control integration the likely source.

---

Observed behavior:

• 244-byte notifications fit into one HCI ACL packet and reconnect remains healthy.

• 245-byte notifications cross the HCI ACL fragmentation boundary.

• On reconnect, 245-byte sends work for four firmware-side sends, then request id=5 is registered successfully but no L2CAP_EVENT_CHANNEL_CAN_SEND_NOW callback arrives.

• After that, every later att_server_register_can_send_now_callback() returns 12, which is ERROR_CODE_COMMAND_DISALLOWED.

• In att_server.c, that return comes from btstack_linked_list_add_tail() failing because the same callback registration is still already in att_server->notification_requests.

The HCI window is the important clue: after the fourth fragmented 245-byte notification, there is no following EVT <= 13 Number Of Completed Packets event before the next send request. That prevents BTstack from producing the next can-send-now event, leaving the notification callback stuck in the pending list.

---

this is as far as i can help/investigate i think. next steps would require me to recompaile the pre-compiled arduino pico objects like liblwip-bt.a and i feel like im already unverqualified to investigate this.

from what i understand this issue is caused in the btstack integration into the arduino pico core and free rtos.
i ran a pretty much equivalent code in pico sdk and it caused no issues.

here the AI:

---

Current Hypothesis
The remaining bug source is likely in Arduino-Pico’s BTstack run-loop / CYW43 FreeRTOS integration, not BTstackLib and probably not your app code.

Most suspicious files:
cores/rp2040/sdkoverride/btstack_run_loop_async_context.cpp
cores/rp2040/sdkoverride/cyw43_driver_freertos.cpp
cores/rp2040/sdkoverride/cyw43_arch_freertos.c

[mringwal]

Hi. Just enjoy the weekend. As mentioned, it looks like the callback registration isn’t cleared, so let’s fix this first and see if that’s sufficient Sent from my iPhoneOn 12 Jul 2026, at 08:45, savejeff ***@***.***> wrote:savejeff left a comment (bluekitchen/btstack#740) Ive also ported the notify code to a pico sdk project. here the bug/issue does not occur. here the AIs conclusion: The pure SDK version does not reproduce because the native BTstack/CYW43 run loop handles the post-reconnect fragmented notification path correctly. The Arduino-Pico version fails when notifications exceed 244 bytes, meaning the packet crosses the 251-byte controller data boundary and requires fragmentation. After reconnect, one can-send callback registration remains pending, but the expected lower-layer completion/can-send chain never comes back. That suggests stale or lost state in the Arduino-Pico BTstack/CYW43 async integration, especially around ACL buffer credits or completed-packet processing. So the current best narrowed statement is: The bug is not caused by large MTU alone. It appears when a notification payload exceeds 244 bytes, causing the ATT notification plus ATT/L2CAP headers to exceed 251 bytes and require lower-layer fragmentation. The failure only appears in the Arduino-Pico integration, not in the pure Pico SDK implementation, making the Arduino-Pico BTstack/CYW43 run-loop or ACL flow-control integration the likely source. —Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you commented.Message ID: ***@***.***>