LL_ASSERT in event_common_prepare

[zephyrbot]

Reported by Johan Hedberg:

When doing simultaneous scanning and advertising (advertising getting enabled when scanning is already enabled), the following assert is observed:

{code}
#0 0x000008d0 in bt_controller_assert_handle (file=0xb0cd "",
file@entry=0xb094 "/home/jh/src/zephyr/subsys/bluetooth/controller/ll/ctrl.c", line=line@entry=3811)
at /home/jh/src/zephyr/samples/bluetooth/hci_uart/src/main.c:308
#1 0x00004304 in event_common_prepare (ticks_at_expire=ticks_at_expire@entry=7351094, remainder=,
ticks_xtal_to_start=ticks_xtal_to_start@entry=0x200006b0 <_radio+432>,
ticks_active_to_start=ticks_active_to_start@entry=0x200006b4 <_radio+436>, ticks_preempt_to_start=0,
ticker_id=ticker_id@entry=6 '\006', ticker_timeout_fp=ticker_timeout_fp@entry=0x5505 <event_obs>,
context=context@entry=0x0 <__k_mem_pool_quad_block_size_define>)
at /home/jh/src/zephyr/subsys/bluetooth/controller/ll/ctrl.c:3811
#2 0x000046be in event_obs_prepare (ticks_at_expire=7351094, remainder=, lazy=,
context=) at /home/jh/src/zephyr/subsys/bluetooth/controller/ll/ctrl.c:4175
#3 0x000022ea in ticker_worker (instance=0x20000448 <_instance>)
at /home/jh/src/zephyr/subsys/bluetooth/controller/ticker/ticker.c:393
#4 0x000016a4 in mayfly_run (callee_id=callee_id@entry=0 '\000')
at /home/jh/src/zephyr/subsys/bluetooth/controller/util/mayfly.c:116
#5 0x00008cac in rtc0_nrf5_isr (arg=)
at /home/jh/src/zephyr/subsys/bluetooth/controller/hci/hci_driver.c:183
#6 0x00009f08 in _idle_state_cleared () at /home/jh/src/zephyr/arch/arm/core/isr_wrapper.S:108
{code}

{code}
< HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1 [hci1] 21.201759
10:14 AM Advertising: Enabled (0x01)
10:14 AM > HCI Event: Command Complete (0x0e) plen 4 [hci1] 21.207483
10:14 AM LE Set Advertise Enable (0x08|0x000a) ncmd 1
10:14 AM Status: Success (0x00)
10:14 AM > HCI Event: Vendor (0xff) plen 12 [hci1] 21.217440
10:14 AM aa 63 74 72 6c 2e 63 00 e3 0e 00 00 .ctrl.c.....
{code}

(Imported from Jira ZEP-1839)

[zephyrbot]

by Carles Cufi:

Setting XTAL_ADVANCED to 0 makes the issue disappear

[zephyrbot]

by Johan Hedberg:

Can be easily reproduced with this: https://gerrit.zephyrproject.org/r/11900

[zephyrbot]

by Vinayak Kariappa Chettimada:

Controller asserted in preparation of a role event due to
the previous (same or another) role event preparation being
not complete.

Mayfly callee was disabled in the previous event due to the
preparation time being short and previous start running
(higher natural priority) before all previous preparation
mayfly completed. The previous start disabled mayfly to
avoid Radio ISR latencies.

The current role event that asserted, preempted the
previous role (observer role with continuous scanning
window) which runs until preemption to maximise the Radio
h/w use (observer scanning until next interval). The
previous preparation mayfly is still disabled when the
current role preparation tries to use same mayfly instance
which should be free for a new enqueue.

The fix updates mayfly implementation so that mayfly
callee is disabled only after all enqueued mayfly instances
are run to completion.

[zephyrbot]

by Mark Linkmeyer:

Hi Johan Hedberg , can you please verify this bug is fixed? Sharron has marked it as requiring verification by the reporter, and that's you. :-)