MPSL Assert 3,39

[grantrudd]

Hello,

We are seeing an intermittent MPSL assert with the code 3, 39. Can you tell us what this code points to?

Thanks,

Grant

[Edvin]

Hello Grant,

Can you please specify what device you are using, and what NCS version you are using?

Best regards,

Edvin

[grantrudd]

Hi Edvin,

This is on an nRF52840 with NCS version 3.2.4 (ANT+ SDK 2.1.0). We are seeing this assert with BLE, ANT+ and a proprietary protocol running concurrently.

[Edvin]

Hello Grant,

According to our MPSL team, this is not a known issue from our side.

"It might be the customer or ANT is doing something wrong, like calling mpsl_timeslot_request twice on the same session (but in that case it should have been caught in mpsl_timeslot layer and not reach this assert."

Can you please provide a backtrace/callstack when the assert occurs? It may be caused by some API from the incorrect execution priority. Please see:

https://nrfconnectdocs.nordicsemi.com/ncs/latest/nrfxlib/mpsl/doc/mpsl.html#thread-and-interrupt-safety

Best regards,

Edvin

[grantrudd]

Hi Edvin,

That's good feedback, thank you. Our application requests timeslots in three situations:

1) We need access to the radio and we don't have it. In this case we use `mpsl_timeslot_request` from thread context. We always make the request, even if we're already in a timeslot, because the docs say this should return safely:

nrfconnectdocs.nordicsemi.com/.../group__mpsl__timeslot_ga941d3f7a80676fc0f94e18155b175ea5.html
> -NRF_EAGAIN The session is not IDLE, or the first request in a session was a MPSL_TIMESLOT_REQ_TYPE_NORMAL

2) Our extension request failed and we return `MPSL_TIMESLOT_SIGNAL_ACTION_REQUEST` from the EXTENSION_FAILED signal handler.

3) In BLOCKED/CANCELLED scenarios, we use `mpsl_timeslot_request`. We only use `EARLIEST`, so the docs hint that an earliest request cannot be blocked or cancelled. Is that true?

For all requests, we use the same parameters:

* request_type = MPSL_TIMESLOT_REQ_TYPE_EARLIEST

* hfclk = MPSL_TIMESLOT_HFCLK_CFG_XTAL_GUARANTEED

* priority = MPSL_TIMESLOT_PRIORITY_NORMAL

* timeout_us =1000000

Can you elaborate on the exact conditions for that assert to occur?

Could it be getting an EXTENSION_FAILED signal in (from ISR context) the middle of calling `mpsl_timeslot_request`?

Getting a backtrace of this might be difficult, as we see it very infrequently and generally in a non-instrumented environment. We will try though!

Thanks,

Grant