Hi, I am using NCS v2 and the VSCode NCS extension writing in C++.
I am seeing Timer0 not fire more than once for me after the MPSL_TIMESLOT_SIGNAL_START event.
Ultimately, as an MPSL timeslot time nears its end, I want to try several different requests with MPSL, like extending the timeslot, and if that fails, to request a subsequent timeslot.
In my understanding, the only way to make requests to MPSL is to return an indicative value from an MPSL-issued callback.
I'm trying to trigger MPSL to call me (so that I can request things in the reply) by causing Timer0 to trip, thereby causing MPSL_TIMESLOT_SIGNAL_TIMER0, thereby giving me my chance to return my request.
Resources I've consulted
1) The Nordic documentation on MPSL timeslots (link)
It indicates you can make requests to extend but does not indicate how.
I cannot find any answer to this question in the API documentation either.
No MPSL examples from Nordic that I can find show this either.
Hence my attempt was to trigger Timer0 events to get my chance.

2) This devzone article RE: Trigger radio signal in multiprotocol. and its (link) implementation showing the details.
"NRF_TIMER0->EVENTS_COMPARE[1] event ... When this even is triggered the softdevice will signal NRF_RADIO_CALLBACK_SIGNAL_TYPE_TIMER0"
If I'm understanding it right, it is saying that two different CC triggers are monitored by MPSL and somehow influence (how?) whether the NRF_RADIO_CALLBACK_SIGNAL_TYPE_TIMER0 is called?
I have tried using the CC[1] and it does not cause Timer0 to fire again after the first use of CC[0]. Meaning I can't get Timer0 to fire a second time after using CC[0] the first time, regardless of whether I trigger it on CC[0] or CC[1].
I'm confused by this.
From the Nordic Timeslot page I linked above:
For these purposes, 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. The recommended practice is to set up a timer interrupt that expires before the timeslot expires, with enough time left for the timeslot to do any clean-up actions before the timeslot ends. Such a timer interrupt can also be used to request an extension of the timeslot, but there must still be enough time to clean up if the extension is not granted.
This technically could still be in line with the devzone response of #2, but it would have to be so vaguely interpreted to be compatible.
A simplistic reading of this would be "You get Timer0 to play with during the slot, do whatever you want."
From my experience, I'd also add to the meaning that "Whenever you trip Timer0 you get a callback via NRF_RADIO_CALLBACK_SIGNAL_TYPE_TIMER0."
As in, no special meanings associated with tripping Timer0 other than that you get a chance to wake up and talk to MPSL.
Question 1
My thought was that Timer0 interrupts always caused MPSL to fire the MPSL_TIMESLOT_SIGNAL_TIMER0 event, giving me a chance to do whatever I wanted.
Is that true?
Question 2
Are there multiple CC channels that need to be operated, differently from one another?
What is the specific meaning of each, and what is the specific way they are meant to be used?
Question 3
Can Timer0 be used multiple times within a given timeslot?
Can I clear (NRF_TIMER0->TASKS_CLEAR), start (NRF_TIMER0->TASKS_START), and stop (NRF_TIMER0->TASKS_STOP), etc, at will, and expect MPSL_TIMESLOT_SIGNAL_TIMER0 to be fired?
How does that answer change depending on whether it's CC[0...3]?
Question 4
If none of the above answers this question, what is the right way to make multiple requests to MPSL during a timeslot?
Recall, my objective is to
- Start the timeslot
- Set a timer near the end of the slot
- Request an Extension
- If the extension fails, Request a subsequent slot
A Few Thoughts
The documentation for the interface to MPSL is very very sparse.
The API page an inventory, not an explanation.
The examples from Nordic I can find for MPSL are very minimal in their implementation in how they exercise the API (as in, they don't exercise all aspects of the API).
Nordic should put more narration around the API documentation, showing concrete specific details of how to work the API under common and expected use cases (eg extending multiple times, finally rejected, ultimately asking for next slot). Others too I'm sure.
Thanks.