Hi,
we are working on a device based on a nrf52840 using zephyr 3.2, which uses bluetooth low energy for advertising and for providing some services with some characteristics.
When building our application in debug mode, which has a lot of logging output, we are quite often encountering the following kind of assertions:
ASSERTION FAIL [!radio_is_ready()] @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/ll_sw/nordic/lll/lll_conn.c:573
[00:01:13.253,601] <err> os: r0/a1: 0x00000003 r1/a2: 0x2002bddc r2/a3: 0x00000000
[00:01:13.253,631] <err> os: r3/a4: 0x00000000 r12/ip: 0x00000000 r14/lr: 0x00084743
[00:01:13.253,631] <err> os: xpsr: 0x61000011
[00:01:13.253,662] <err> os: s[ 0]: 0x00000000 s[ 1]: 0x00000000 s[ 2]: 0x00000000 s[ 3]: 0x00000000
[00:01:13.253,692] <err> os: s[ 4]: 0x00000000 s[ 5]: 0x00000000 s[ 6]: 0x00000000 s[ 7]: 0x00000000
[00:01:13.253,692] <err> os: s[ 8]: 0x00000000 s[ 9]: 0x00000000 s[10]: 0x00000000 s[11]: 0x00000000
[00:01:13.253,723] <err> os: s[12]: 0x00000000 s[13]: 0x00000000 s[14]: 0x00000000 s[15]: 0x00000000
[00:01:13.253,723] <err> os: fpscr: 0x000abed8
[00:01:13.253,753] <err> os: Faulting instruction address (r15/pc): 0x0008474e
[00:01:13.253,784] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:01:13.253,814] <err> os: Fault during interrupt handling
[00:01:13.253,845] <err> os: Current thread: 0x20008de0 (idle)
[00:01:13.314,453] <err> os: Halting system
It seems that there is some kind of timing-problem going on, because the assertion occurs more often, if more logging output is enabled. It occurs extremely often, when CONFIG_PRINTK_SYNC is enabled.
And we encountered another possibly related problem, which also does only occur in debug mode. When this happens, other bluetooth low energy receiving devices are showing up one or more additional advertising devices, with kind of randomly selected addresses, which do not exist. It seems that all the bluetooth advertising air-traffic gets totally mixed up from the one zephyr device in debug mode. We used the nrf-sniffer to analyze more deeply whats going on in this situation, but we found only totally weird stuff.
So we are having the hope that the crazy advertising is also caused by some timing problems ... and when having a solution for the assertion, this might also solve the problem with the crazy advertising.
Does anybody know anything about the assertion?
Are there some general rules about how to setup a project with bluetooth low energy in terms of thread scheduling and stuff like that?
Regard
Volker
