Softdevice Controller ASSERT filename/linenumber

RE: Softdevice Controller ASSERT filename/linenumber

Einar Thorsrud — Tue, 11 Jun 2024 10:21:38 GMT

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).

[quote user="Jonathan E"]Also, can it be caused by the fact that I am connected to six devices at the same time with coded phy enabled?[/quote]

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.

RE: Softdevice Controller ASSERT filename/linenumber

Jonathan E — Mon, 10 Jun 2024 10:51:24 GMT

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?

RE: Softdevice Controller ASSERT filename/linenumber

Einar Thorsrud — Mon, 10 Jun 2024 10:42:37 GMT

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.

RE: Softdevice Controller ASSERT filename/linenumber

Jonathan E — Mon, 10 Jun 2024 08:11:42 GMT

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.

RE: Softdevice Controller ASSERT filename/linenumber

Turbo J — Mon, 10 Jun 2024 08:06:10 GMT

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.