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?

[Susheel Nuguru]

I always assumed that you need to reconfigure the timer when you get the start signal, you cannot assume of the initial state of the underlying timer when you get control of it inside the timeslot.

[SebastianA]

The documentation about Timeslot -> "Ending a timeslot in time" says; "the application is granted access to the TIMER0 peripheral for the length of the timeslot. This timer is started from zero at the start of the timeslot and is configured to run at 1 MHz".

I've assumed TIMER10 is used instead of TIMER0 here, but maybe this is only valid for MCUs with TIMER0? TIMER10 is running fine for the first timeslot anyway, just like TIMER0 did for nRF52.

[Susheel Nuguru]

You are right, looking into the source codes TIMER10 of nRF54L should have behaved the same way as the sources treats them the same. I will get some help from the low level teams as the source code shows me they should behave same.