Zephyr observer app with CONFIG_BT_EXT_ADV=y triggers bt_ctlr_assert_handle

[Joerg Wunsch]

On a 52840 USB stick, I successfully tested the "observer" demo app.

Now, I tried to extend it by enabling CONFIG_BT_EXT_ADV=y which is supposed to print some details about received advertisements.

This triggers an "assertion failed". I installed bt_ctlr_assert_handle, and it says "file 53, line 826". OK, at least it's not "file 42" :-), but nevertheless I'm at a loss what the assertion wants to tell me. It apparently triggers inside the nRF library code, in a function with an obfuscated name (sym_476LRB5XNUARAHCHHC7ZAIGPFC5VZ4W2N4467LI), with the Bluetooth Rx thread.

Can anyone enlighten me what's the cause of this failed assertion?

[Einar Thorsrud]

Hi,

That is not expected. The sample should work also if you add  CONFIG_BT_EXT_ADV=y, and you should see an additional line in the log for every received advertising packet (with additional information about extended advertising packets). This seems to work out of the box on nRF Connect SDK 2.1.2 when I test.

Which nRF Connect SDK version are you using, and did you do any other changes? If you don't make progress, can you elaborate and copy-paste the full log (at least everything related to the assert) here?

[Joerg Wunsch]

The SDK is 2.2.0-rc1. I'm using it on Linux, and 2.1.x apparently lacked all the CMSIS stuff there, so I could not use it at all (at least, not without additional fiddling).

The only other change is that I enabled the serial console in Kconfig. I reverted everything to CONFIG_BT_EXT_ADV=n, and it immediately works again as intended.

Any idea what the assertion is supposed to be at? Due to the library obfuscation, without knowing what a file named "53" might refer to, there's not much clue about it on the end-user's side.

[Einar Thorsrud]

Hi,

Joerg Wunsch said:

The SDK is 2.2.0-rc1.

I tested this with 2.2.0 release now and it also works as expected on my end (using the toolchain manager on Ubuntu 22.04 LTS).

Joerg Wunsch said:

and 2.1.x apparently lacked all the CMSIS stuff there, so I could not use it at all (at least, not without additional fiddling).

What are you referring to here? The nRF Connect SDK 2.1.x has everything included, and if you are using a recent Ubuntu you can even use the tooclhain manger to get everything bundled together so you get a complete system out of the box. If you install manually, you need to carefully follow the instructions to get everything.

Joerg Wunsch said:

Any idea what the assertion is supposed to be at?

No, this does not ring any bells. But it would be good to know more about the assert (a full dump of the log) where you see this assert. And also, any other changes you have done to the project (you write USB, so perhaps you modified it to use USB CDC ACM instead of UART etc, which may not be related, but it makes me wonder if you have made more changes.)

[Joerg Wunsch]

Hello Einar,

I have no idea why, but in my case, the 2.1.2 version lacked a lot after being installed (through the Toolchain manager).

$ find v2* -name core_cm4.h
v2.1.2/modules/lib/loramac-node/src/boards/mcu/stm32/cmsis/core_cm4.h
v2.1.2/modules/lib/loramac-node/src/boards/mcu/saml21/cmsis/core_cm4.h
v2.1.2/modules/tee/tf-m/trusted-firmware-m/platform/ext/cmsis/core_cm4.h
v2.1.2/modules/bsim_hw_models/nrf_hw_models/src/HW_models/core_cm4.h
v2.2.0-rc1/modules/lib/loramac-node/src/boards/mcu/stm32/cmsis/core_cm4.h
v2.2.0-rc1/modules/lib/loramac-node/src/boards/mcu/saml21/cmsis/core_cm4.h
v2.2.0-rc1/modules/tee/tf-m/trusted-firmware-m/platform/ext/cmsis/core_cm4.h
v2.2.0-rc1/modules/bsim_hw_models/nrf_hw_models/src/HW_models/core_cm4.h
v2.2.0-rc1/modules/hal/cmsis/CMSIS/Core/Include/core_cm4.h

The entire "modules/hal/cmsis" is just empty there. Consequently, when trying to compile, it complained about a missing core_cm4.h file.

But since 2.2.0 appears to be released now, it doesn't make a lot of sense to investigate why that happened, I think.

There are two other chances:

1) CONFIG_FLASH_LOAD_OFFSET=0x0 because I'm programming directly with a J-Link.

2) I'm toggling LED0 at the end of device_found()

What log exactly would you need? Here's the the call stack from the exception:

mpsl_assert_handle(const char * file, uint32_t line) (/home/WUJ2DR/BST/nordic/observer/src/observer.c:136)
m_assert_handler(const char * const file, const uint32_t line) (/home/WUJ2DR/BST/ncs/v2.2.0-rc1/nrf/subsys/mpsl/init/mpsl_init.c:168)
sym_S2UAPMFVIQXDUOA6CV7GJMB33TYHEUH5D6LHO5Q (Unknown Source:0)
sym_J5F7QGRFPKMLWRNSXZXS5YI7BM4DUTISCOASCOA (Unknown Source:0)
MPSL_IRQ_TIMER0_Handler (Unknown Source:0)
mpsl_timer0_isr_wrapper_body() (/home/WUJ2DR/BST/ncs/v2.2.0-rc1/nrf/subsys/mpsl/init/mpsl_init.c:130)
mpsl_timer0_isr_wrapper() (/home/WUJ2DR/BST/ncs/v2.2.0-rc1/nrf/subsys/mpsl/init/mpsl_init.c:128)
<signal handler called> (Unknown Source:0)
arch_cpu_idle() (/home/WUJ2DR/BST/ncs/v2.2.0-rc1/zephyr/arch/arm/core/aarch32/cpu_idle.S:108)
k_cpu_idle() (/home/WUJ2DR/BST/ncs/v2.2.0-rc1/zephyr/include/zephyr/kernel.h:5627)
idle(void * unused1, void * unused2, void * unused3) (/home/WUJ2DR/BST/ncs/v2.2.0-rc1/zephyr/kernel/idle.c:83)
z_thread_entry(k_thread_entry_t entry, void * p1, void * p2, void * p3) (/home/WUJ2DR/BST/ncs/v2.2.0-rc1/zephyr/lib/os/thread_entry.c:36)
[Unknown code] (Unknown Source:0)

[Einar Thorsrud]

Hi,

This gives a bit more info. The assert is an MPSL assert. If you get this issue wiht 2.2.0 let me know and copy this and the numbers you get (ala "file 53, line 826"), and I will check.

(Without doing that I can say that the most common reason for getting a MPSL assert is that MPSL looses timing, for instance because the application has some high priority operation that takes a long time, uses long critical section, or simply because of debugging with breakpoints or stepping.)

Regarding the missing files it sounds like checkout of the SDK failed. Unfortunately the toolchain manager can faile silently in soem cases. What you can do then is to either open a terminal from the toolchain manager and issue a "west update" command, or click the downwards arrow to the right of the SDK version and select "Update SDK".

[Joerg Wunsch]

The file name / line numbers are exactly that (as mentioned in my first message), file "53", line 826.

OK, timing issue might explain it a bit, parsing the message probably takes some time. I could rearrange the code to only record the message details in the callback, and then parse it later. Probably a good idea anyway.

Sorry, yes, I mistyped the assert handler in the first message: of course, an MPSL assert (I had a BT CTRL assert once as well, so I installed both handlers).

[Joerg Wunsch]

*** Booting Zephyr OS build v3.2.99-ncs1-rc1 ***
Starting Observer Demo
Registered scan callbacks
Started scanning...
Device found: 03:02:68:F7:A6:79 (random) (RSSI -72), type 3, AD data len 15
[DEVICE]: 01:04:89:20:00:52 (0x40), AD evt type 0, Tx Pwr: 1, RSSI -84 Data status: 0, AD data len: 15 Name: C:1 S:0 D:0 SR:0 E:0 Pri PHY: Unknown, Sec PHY: Unknown, Interval: 0x0000 (0 ms), SID: 183
Device found: 03:02:68:F7:A6:79 (random) (RSSI -72), type 3, AD data len 15
[DEVICE]: 01:04:89:20:00:52 (0x40), AD evt type 0, Tx Pwr: 1, RSSI -84 Data status: 0, AD data len: 15 Name: C:1 S:0 D:0 SR:0 E:0 Pri PHY: Unknown, Sec PHY: Unknown, Interval: 0x0000 (0 ms), SID: 183

Rearranged the code. scan_recv() now just records both pointers, and there's a separate scan_print() (called from the main thread) that arranges for the printout of recorded data. That works as expected.

Thanks for pointing out that the assertion is a timing issue, that was the key to solve it.