Softdevice Controller ASSERT filename/linenumber

[Jonathan E]

Hi,

I am debugging an application whth MPSL enabled and occasionally get this error:

E: SoftDevice Controller ASSERT: 48, 190

E: ***** HARD FAULT *****
E: Fault escalation (see below)
E: ARCH_EXCEPT with reason 3

E: r0/a1: 0x00000003 r1/a2: 0x20013257 r2/a3: 0x00000000
E: r3/a4: 0x00075b89 r12/ip: 0x00000000 r14/lr: 0x00077a0f
E: xpsr: 0x41000011
E: s[ 0]: 0x7f7fffff s[ 1]: 0x3eaaaaab s[ 2]: 0x00000000 s[ 3]: 0x00000000
E: s[ 4]: 0x00000000 s[ 5]: 0x00000000 s[ 6]: 0x00000000 s[ 7]: 0x00000000
E: s[ 8]: 0x00000000 s[ 9]: 0x00000000 s[10]: 0x00000000 s[11]: 0x00000000
E: s[12]: 0x00000000 s[13]: 0x00000000 s[14]: 0x00000000 s[15]: 0x00000000
E: fpscr: 0x00000000
E: Faulting instruction address (r15/pc): 0x00077a1a
E: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
E: Fault during interrupt handling

The message Softdevice controller assert is triggered by:

void sdc_assertion_handler(const char *const file, const uint32_t line)

So my first question is how do I find out which file the number 48 represents?

I am using NCS 2.6.0

[Turbo J]

Softdevice Asserts usually originate from the softdevice not being able to meet required BTLE timings - VERY common when debugging since that disables the MCU core. That means you cannot "continue" from a breakpoint whenever BTLE was active.

Workaround is to setup logging so you never have to continue after hitting a breakpoint - or to not have BTLE enabled.

[Jonathan E]

Hi,

Thanks for your reply. Debugging is not active in my case. I am allowing up to 6 connections with coded phy enabled. The speed is set to 0x0028 at first when connecting to a device, but is slowed down to 0x01f4 after discovery is completed.

[Einar Thorsrud]

Hi,

I have checked the assert, and it is caused by an overstay event in the scheduler in MPSL. This is because the MPSL has been pevented from doing a task on time. This can often be caused by debugging as Turbo J  described, but also by othe rsame or higher priority threads or interrupts. The assert itself does not tell us more about what caused this.

[Jonathan E]

Do you know which priority the BT-thread has by default?

Also, can it be caused by the fact that I am connected to six devices at the same time with coded phy enabled?

[Einar Thorsrud]

Hi,

There are several Bluetooth related threads, the easiest way to see which priroty they all have is to look at the thrad viewer:

Most of these priorities can be modified via Kconfig (like CONFIG_BT_RX_PRI for the RX thread).

Jonathan E said:

Also, can it be caused by the fact that I am connected to six devices at the same time with coded phy enabled?

Yes, I cannot say exactly what the issue is, but the more that has to be scheduled, the higher the likelihood that a bug will manifest itself as there is less headroom.