MPSL timeslot API stops TIMER10 at IDLE and doesn't restart it?

[SebastianA]

I'm porting some code from nRF52832/nRF52840 to nRF54L15 using the MPSL timeslot API. The old code uses MPSL version v2.5.1, the new v2.9.0.

The firmware opens a session and then schedules a timeslot. In the end the timeslot handler returns the END request, it gets a MPSL_TIMESLOT_SIGNAL_SESSION_IDLE and then it just returns NONE.

We don't close the session here.

Some time later we schedule a new timeslot with the same session id. The handler gets the START signal, but this time TIMER10 is not running. For nRF52, with the old version, TIMER0 was started for the new timeslot as well.

Is this a bug or is this the expected behaviour with v2.9.0?

[Hieu]

Hi SebastianA,

We unfortunately don't have such bare metal example.

[Hieu]

Hi SebastianA,

My apology for the last very short reply. I made a mistake and sent it before finishing all I wanted to do.

Susheel is out of office, and while I am honestly quite new to the topic, I am trying to learn and substitute in for the mean time. I hope you can bear with me.

While a bare metal example isn't available, is it possible to use the Timeslot sample to show the issue?

Could you also see if the sample works correctly for the nRF54L15 on NCS v2.9.0 for you? It works fine for me.

Is it possible to check if your timeslot implementation on NCS v2.9.0 works with the nRF52840 or nRF52832?

Hieu

[Susheel Nuguru]

Thanks Hieu for your kind reply. 

Sebastian, The MPSL developer tried to replicate the issue and TIMER10 was running at the start of the timeslot when the same not closed session id was used. It seems something else is happening in your setup or a corner case we cannot reproduce. Please help us reproduce this. I see that TIMER10 in the code is handled the exact same way as other times with macro magic, but maybe what you are seeing might be a hardware glitch in this timer in some special scenario. Hard to know unless we manage to reproduce it here.

[SebastianA]

It is on my todo list to reproduce this in a small example.

From what I can see from the include file, only DPPI channel 0 on PD 10 is used by MPSL. If our code triggers it, could that stop the timer?

We use some one GRTC channel (should only be channel 0) and some TIMER10 capture/compare channels (0-3). Could that cause it to stop?

[Susheel Nuguru]

SebastianA said:

From what I can see from the include file, only DPPI channel 0 on PD 10 is used by MPSL. If our code triggers it, could that stop the timer?

Not sure what you mean by "if your code triggers it"? You should not use any triggers with the resource that MPSL is using.

SebastianA said:

We use some one GRTC channel (should only be channel 0) and some TIMER10 capture/compare channels (0-3). Could that cause it to stop?

This is possible. Can you show me some snippets on how you are using the GRTC and TIMER10 channels and the exact context in which these registers are touched/configured in your application.