ASSERTION FAIL [0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/ll_sw/nordic/lll/lll_adv.c:1041 prepare_cb: Actual EVENT_OVERHEAD_START_US = 3570

[sjanc]

Describe the bug

When running Bluetooth qualification tests AutoPTS we notice some instability and random failures in MESH tests.

Occasionally test fails due to assertion, should EVENT_OVERHEAD_START_US be tuned? (actual value printed in assert differs)

This seems to be affecting MESH tests only (ie I've not noticed those on host tests).
IUT in used in nRF52840 DK.

Regression

• This is a regression.

Steps to reproduce

execute autoPTS MESH tests
./autoptsclient_bot.py -c DFUM/SR/FD/BV-29-C --rtt --debug --stress_test --retry=20

Relevant log output

[00:00:27.553,222] <dbg> bttester_mesh: prov_complete: net_idx 0x0000 addr 0x0002
[00:00:27.553,222] <dbg> bttester: tester_event: service 0x04 opcode 0x83
ASSERTION FAIL [0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/ll_sw/nordic/lll/lll_adv.c:1041
        prepare_cb: Actual EVENT_OVERHEAD_START_US = 3570
[00:00:27.694,976] <err> os: r0/a1:  0x00000003  r1/a2:  0x00000000  r2/a3:  0x00000005
[00:00:27.695,007] <err> os: r3/a4:  0x00000003 r12/ip:  0x20014294 r14/lr:  0x00004f81
[00:00:27.695,007] <err> os:  xpsr:  0x01000028
[00:00:27.695,037] <err> os: Faulting instruction address (r15/pc): 0x00004f90
[00:00:27.695,068] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:00:27.695,098] <err> os: Fault during interrupt handling

[00:00:27.695,129] <err> os: Current thread: 0x200080a8 (idle)
[00:00:36.562,225] <err> os: Halting system

Impact

Intermittent – Occurs occasionally; hard to reproduce.

Environment

Zephyr 39b2451
AutoPTS a6510d24a716c0b61576d082b01c564f2d937cc4

Additional Context

Archive.zip

[sjanc]

for the record: this seems to affect only DFUM and MBTM tests

[cvinayak]

@sjanc are these failing/asserting tests using simultaneous flash operations during advertising and continuous scanning?

[alxelax]

I suspect the total majority (probably all) Mesh tests use flash operations in parallel (over settings subsystem).

I see it happened after provisioning is completed. Mesh (and mbedtls) saves keys (network and device). Mesh stores it in settings, mbedtls in ITS(what is backend for ITS I didn't investigate).

[cvinayak]

May be fixed by #92873.