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.

[Susheel Nuguru]

Sebastian, 

Is it possible that you share a minimalistic project to show this? The low level team might ask for reproducing this before they take this seriously as nothing in the code suggests that this should behave differently.

[SebastianA]

I don't have the time to make a proper minimal example right now, but I did add a check at the end of the timeslot handler just before returning the END request to see that the timer is still running. I did that by capturing the time twice with a busy wait between and then checked that the values differed.

I also added that check when receiving the SESSION_IDLE signal and there the timer has stopped. We don't run any of our code between those two checks (except the low prio irq calling into mpsl).

I also checked the whole codebase for TASKS_STOP, SUBSCRIBE_STOP, timer.*short and timer.*stop (case insensitive), we didn't have any code that could stop any TIMER.

I'll try to create a small example. Do you have a good bare metal example for gcc to build upon?