Bluetooth: Controller: Place holder for a list of known assertions

[cvinayak]

Describe the bug

This is a place holder of a list of Bluetooth Controller assertions in the upstream open source implementation.

To Reproduce

Each assertion have unique use case or scenario under which they can occur, refer to each assertion on how to reproduce and possible reasons under which they can occur.

Expected behavior

No assertions occur under respective use cases scenarios.

Impact

showstopper under these required use cases.

Logs and console output

Environment (please complete the following information):

Refer to individual assertions listed below:

Additional context

• ASSERTION FAIL [0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/ll_sw/nordic/lll/lll_adv.c:1041 prepare_cb: Actual EVENT_OVERHEAD_START_US = 823
  Commit SHA: 8faa486
  Platform: nRF52x/nRF53x/nRF54x and others.
  Reproduce using sample: samples/bluetooth/broadcaster_multiple with CONFIG_BT_EXT_ADV_MAX_ADV_SET=20
  Possible analysis: Processing overhead when many overlapping ticker nodes need ticker_job() to use CPU time, this can delay the ticker_worker() to have higher latency.
  Possible mitigation PR: Bluetooth: Controller: Optimized ticker_job for short ticks_to_expire #87250
  Possibly reduces the latency in this PR: Bluetooth: Controller: Replace prepare pipeline with ordered list #79444

• ASSERTION FAIL [lll_aux] @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/ll_sw/ull_scan_aux.c:278
  Commit SHA: 8faa486
  Platform: nRF52x/nRF53x/nRF54x and others.
  Reproduce using sample: samples/bluetooth/observer with extended scanning of extended advertising with/without chains
  Possible analysis: lll_aux stored in scan context re-used, fix by using lll_aux in node rx instead. Also, refer to eab3f49 for how it is handled in the BT_CTLR_SCAN_AUX_USE_CHAINS feature.
  PR: Bluetooth: Controller: Fix interleaved extended scanning assert #82526

• ASSERTION FAIL [hcto == (start_us + 1U)] @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/ll_sw/nordic/lll/lll_sync_iso.c:1116
  Commit SHA: 6b10383
  Platform: nRF53, nRF54x (and possibly nRF52x)
  Reproduce using audio bsim tests _cap.sh script
  Possible analysis: Listening early considering +/- 2 us active clock jitter, i.e. listening early by 4 us for nse times for current subevent can be in the past
  Problem statement: I do not like the calculations here for the jitter, it is always calculating for nse i.e. from the first subevent; ideally, current jitter should be from the last sync-ed subevent.
  The problem to solve, active clock is permitted a +/-2 us jitter which means over the duration of the subevents, a subevent can jitter by +/- 2 us multiplied by current subevent count nse when none of the previous subevent where received (anchor point sync).
  Possibly fixed by PR: Bluetooth: Controller: Add NRF_CCM support in nRF54L15 SoC #83394. But needs an alternative implementation to correctly consider active clock jitter.
  Possibly fixed (worked around) again: Bluetooth: Controller: Fix missing ISO Receiver address capture #95348
  Possibly fixed (tested to not occur with supervision timeout when going far away listening to music using bap_broadcast_sink on nrf54l15dk + DAC) PR: Bluetooth: Controller: Fix single switch timer use in ISO Sync #96653

• ASSERTION FAIL [instant_latency == 0U] @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/ll_sw/ull_conn_iso.c:1010
  Commit SHA: 6b10383
  Platform: nRF53, nRF54x (and possibly nRF52x)
  Reproduce using audio bsim tests _cap.sh script
  Possible analysis: Missing implementation to handle latency due to skipped ACL events around the instant to start CIG.

• ASSERTION FAIL [next] @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/ll_sw/nordic/lll/lll.c:1004
  Commit SHA: 8faa486
  Platform: nRF54x
  Reproduce using sample: samples/bluetooth/observer with extended scanning of extended advertising with/without chains
  Possible analysis: Missing Radio IRQ due to missing implementation to handle product anomaly if any, or possible bug in the Controller implementation that is not pre-empting radio use and hence overflowing the prepare pipeline.
  Possibly fixed by PR: Bluetooth: Controller: Add NRF_CCM support in nRF54L15 SoC #83394.
  Was again observed, and now possibly fixed by PR: Bluetooth: Controller: Fix conn timeout due to delayed conn upd ind #92572

• ASSERTION FAIL [start_us == (aux_start_us + 1U)] @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/ll_sw/nordic/lll/lll_scan_aux.c:358
  Reproduced using sample: samples/bluetooth/observer with extended scanning of extended advertising with/without chains
  Possible analysis: Active mode extended scanning assert raised when calling radio_tmr_start_us() due to stale radio_tmr_end_get() value. Active mode extended scanning did not drop reception of ADV_EXT_IND PDU when setup to receive ADV_SCAN_RSP PDUs.
  Possibly fixed by PR: Bluetooth: Controller: Fix extended scanning assertion and fix single timer direction finding support #86174.

• ASSERTION FAIL [lll] @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/ll_sw/ull_scan_aux.c:1203
  Possibly fixed by PR: Bluetooth: Controller: Fix extended scanning assert on invalid chan_idx #94575, commit d7256dc

• ASSERTION FAIL [0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/ll_sw/nordic/lll/lll_central.c:256

  d_00: @00:00:03.728365  (CPU:1): ASSERTION FAIL [0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/ll_sw/nordic/lll/lll_central.c:256
  d_00: @00:00:03.728365  (CPU:1): 	prepare_cb: Actual EVENT_OVERHEAD_START_US = 17852
  
  

  Reproduced using: BOARD=nrf5340bsim/nrf5340/cpuapp tests/bsim/bluetooth/audio/test_scripts/csip_no_lock.sh
  Possible analysis: Delayed scan event done due to race with continuous scan window being put back as resume event in the LLL pipeline, and there is another prepare event that starts using the radio. The connection setup is delayed until this race prepare event is done and the resume scan event gets to be done/reduce its ref count.
  Possibly fixed by PR: Bluetooth: Controller: Fix conn timeout due to delayed conn upd ind #92572, commit c7366cf

• ASSERTION FAIL [err == 0 || err == -114] @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/ll_sw/ull_scan.c:657

  d_00: @00:00:14.915931  ASSERTION FAIL [err == 0 || err == -114] @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/ll_sw/ull_scan.c:657
  d_00: @00:00:14.915931  	param1: 0 param2: 4294967285
  d_00: @00:00:14.915931  @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/ll_sw/ull_scan.c:657
  

  Possibly fixed by PR: Bluetooth: Controller: Fix conn timeout due to delayed conn upd ind #92572, commit 1354251

• ASSERTION FAIL [err == 0 || err == -120] @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/ll_sw/ull_scan.c:657
  The issue was reproduced again 2025-10-29 on a nrf54l15dk with a sample that combines broadcaster_multiple and observer and adds periodic calls to scan_disable and scan_enable.

  [2025-10-29 23:59:44] ASSERTION FAIL [err == 0 || err == -120] @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/ll_sw/ull_scan.c:657
  [2025-10-29 23:59:44]   param1: 1 param2: 4294967285
  

  Trying again to fix in PR: Bluetooth: Controller: Fix ull_disable() assert at k_sem_take() #98508, but this is not right; issue is not a instruction re-ordering issue, the issue is reproduced when both 1M and Coded PHY scanning is active.

• ASSERTION FAIL [0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/ll_sw/ull_iso.c:1828

  d_00: @00:00:00.022771  [00:00:00.022,766] <err> bt_ctlr_ull_iso: Tx Buffer Overflow
  d_00: @00:00:00.022771  ASSERTION FAIL [0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/ll_sw/ull_iso.c:1828
  

• ASSERTION FAIL [err == ((isoal_status_t) 0x00) || err == ((isoal_status_t) 0x04)] @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/hci/hci_driver.c:616

• ASSERTION FAIL [start_us == (subevent_us + 1U)] @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/ll_sw/nordic/lll/lll_peripheral_iso.c:859
  GH Issue: Bluetooth: Controller: ISO: BAP unicast server fails to establish CIS with Google Pixel - Connection Failed/Sync Timeout (0x3e) #95254

nRF51 Specific Assertions

• ASSERTION FAIL [start_us == (aux_start_us + 1U)] @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/ll_sw/ nordic/lll/lll_scan_aux.c:359
  This will happen for small aux offset value, definitely for the 300 us because CPU usage latency to setup such auxiliary PDU reception on nRF51 is high due to slow CPU.
  This can be work around by checking for small offsets that can not be scheduled for and mitigate needing to assert. Only extended advertising with sufficient aux offset will be the ones that nRF51 report.
  Refer to: samples: Bluetooth: observer: Extended Scanning on BBC Micro Bit board #95191
  Mitigated by: Bluetooth: Controller: Fix Extended Scanning for slow CPUs #98267

• ASSERTION FAIL [0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/ll_sw/ nordic/lll/lll_scan_aux.c:592
prepare_cb: Actual EVENT_OVERHEAD_START_US = 579
  This will happen due to CPU usage latencies scheduling the radio events, due to slow CPU.
  This is easily work around by increasing the EVENT_OVERHEAD_START_US value in lll_vendor.h on a per usecase basis (CPU usage).
  Refer to: samples: Bluetooth: observer: Extended Scanning on BBC Micro Bit board #95191
  Possibly fixed by: samples: Bluetooth: observer: Fix Extended Scanning on BBC Micro:bit #98358

[fbenamrouche]

I'm getting the following assert that is not in the list above:

ASSERTION FAIL [0] @ ZEPHYR_BASE/subsys/bluetooth/controller/ll_sw/nordic/lll/lll_peripheral.c:337
        prepare_cb: Actual EVENT_OVERHEAD_START_US = 305

This happens when we do heavy BLE download (OTA), while writing to the flash the chunks we received. (to speed up the download, we renegociate the connection parameters to more aggressive values {Interval 6, latency 0, timeout 72})
Tried to change the default IRQ priority to 5 to no avail.

For now, disabling CONFIG_BT_CTLR_ASSERT_OVERHEAD_START avoid this error, but I don't know the consequences!

[cvinayak]

@fbenamrouche

CONFIG_BT_CTLR_ASSERT_OVERHEAD_START is safe to use, but masks bad performance.

Which SoC and commit version is your application built for?

[fbenamrouche]

I'm using the 52840, zephyr 4.0.
What do you mean by bad performance? Lost packets? or just slower that optimal BLE speed?

[cvinayak]

I'm using the 52840, zephyr 4.0.

Please open a new GitHub issue with details of reproducing the issue on nRF52840DK. Provide the command line so that I can reproduce it at my end.

What do you mean by bad performance? Lost packets? or just slower that optimal BLE speed?

Slow throughput or complete hang (without a disconnection complete), i.e. if occasional overhead or repeated overhead on every connection event, respectively.