MPSL ASSERT 106, 701 and SoftDevice Controller assert 48, 1403

RE: MPSL ASSERT 106, 701 and SoftDevice Controller assert 48, 1403

Einar Thorsrud — Wed, 30 Apr 2025 08:16:35 GMT

Hi,

The problem here seems to be that you call mpsl_timeslot_request() from an interrupt, which is not allowed. You should call it from a non-preemtable thread to make sure there are no parallell MPSL API calls. You can see an example of that here in the MPSL timeslot sample, and refer to the documentation here.

PS: The reason this happens more when doing DFU is proably because flash writes are done via MPSL, so the likelyhood of collisions increase in this case.

RE: MPSL ASSERT 106, 701 and SoftDevice Controller assert 48, 1403

Robin J — Tue, 29 Apr 2025 09:10:44 GMT

Hi,

I've now managed to reproduce the issue with a minimal example based on the MPSL timeslot sample included in nRF Connect SDK it also includes code from the SMP server sample to enable advertising.

It mostly triggers the SoftDevice Controller assert but it sometimes triggers the MPSL assert as well.

To trigger the asserts, one has to use the nRF Device Manager mobile app and do a firmware upgrade through it. It might take some retries to make it trigger.

Here is the example code/project: devzone.nordicsemi.com/.../4520.timeslot.zip

RE: MPSL ASSERT 106, 701 and SoftDevice Controller assert 48, 1403

Einar Thorsrud — Mon, 14 Apr 2025 07:41:28 GMT

Hi,

We are looking at this but are struggling to understand and reproduce the issue. Would it be possible to share a (preferably as minimal as possible) project along with instructions on how to reproduce so that we can test the same his on our end?

RE: MPSL ASSERT 106, 701 and SoftDevice Controller assert 48, 1403

Einar Thorsrud — Mon, 07 Apr 2025 13:12:06 GMT

Hi,

Thank you. I am disussing this internally and will update here.

RE: MPSL ASSERT 106, 701 and SoftDevice Controller assert 48, 1403

Robin J — Mon, 07 Apr 2025 11:13:58 GMT

Our timeslots run at most every 10 ms and scheduled expected duration is 10 ms.
They are requested with MPSL_TIMESLOT_PRIORITY_HIGH, MPSL_TIMESLOT_HFCLK_CFG_XTAL_GUARANTEED and MPSL_TIMESLOT_REQ_TYPE_NORMAL if it's not the first request of the timeslot session, then it is MPSL_TIMESLOT_REQ_TYPE_EARLIEST.

The connection parameters are default for the BLE SMP sample I think?
Only configuration that is done is this Kconfig configuration:

CONFIG_BT_PERIPHERAL=y
CONFIG_BT=y
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y
CONFIG_MCUMGR_TRANSPORT_BT=y
CONFIG_MCUMGR_TRANSPORT_BT_CONN_PARAM_CONTROL=y
CONFIG_MCUMGR_TRANSPORT_BT_REASSEMBLY=y

RE: MPSL ASSERT 106, 701 and SoftDevice Controller assert 48, 1403

Einar Thorsrud — Fri, 04 Apr 2025 13:24:30 GMT

Hi,

I see. We are looking into this, but in order to undertand more I wonder if you can share more details, such as the simelot request parameters and Bluetooth connection parametrs etc as well?

RE: MPSL ASSERT 106, 701 and SoftDevice Controller assert 48, 1403

Robin J — Wed, 02 Apr 2025 08:23:49 GMT

Hi,

I've only seen it happen during the DFU over BLE transfer. I don't think the connection parameters are changed during the transfer. I'm using the Kconfig options described in FOTA updates on nRF52 to enable MCUmgr SMP over BLE and the upload is done from the nRF Device Manager mobile app.

One thing to note is that I only see the asserts when our proprietary protocol is running and using timeslots at the same time as the BLE DFU transfer is being done. If our protocol is disabled, I don't see any asserts.

RE: MPSL ASSERT 106, 701 and SoftDevice Controller assert 48, 1403

Einar Thorsrud — Wed, 02 Apr 2025 07:05:31 GMT

Hi,

The asserts are related to scheduling in the MPSL and SoftDevice controller, but we need to look a bit more into it to be more specific. You write this issue happens only during DFU over BLE, are the BLE connection parameters changd at this point, or perhaps there is longer packets and/or several packets per connection event? (So that BLE takes more time)? Are there any other factors that stand out when you see this issue?