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

[Robin J]

We are using nRF Connect SDK 2.9.1, Zephyr. The hardware used is a nrf52840dk, rev2.

We have a proprietary protocol that is running concurrently with BLE and uses MPSL API for radio access.

We are now facing a problem when doing DFU over BLE using MCUmgr and BLE as the transport layer. We've followed the "FOTA updates on nRF52 Series" documentation to setup DFU over BLE. The target flash area to store the uploaded firmware to is the internal flash. 

The problem we get is that either MPSL or the SoftDevice Controller asserts during transfer of the firmware. It is either "MPSL ASSERT 106,701" or "SoftDevice Controller ASSERT 48, 1403".

Any suggestion on what it can be that causes the asserts?

[Einar Thorsrud]

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?

[Robin J]

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.

[Einar Thorsrud]

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?

[Robin J]

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

[Einar Thorsrud]

Hi,

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

[Einar Thorsrud]

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?

[Robin J]

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: 4520.timeslot.zip

[Einar Thorsrud]

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.