Bluetooth timeslot: sd_radio_request() takes a few ms which glitches an interrupt

[Liam]

My question is similar to https://devzone.nordicsemi.com/f/nordic-q-a/4272/sd_radio_request-performance-question

I am using the S140 softdevice and the Radio Driver ( github.com/.../nRF-IEEE-802.15.4-radio-driver.). Part of my application requires a interrupt every 1ms which I generate using TIMER2. I notice that when sd_radio_request() is called my interrupt pauses for a few ms. Flashing a LED over sd_radio_request shows that its during its execution time that the interrupt pauses.

The original question (about 4 years old) indicates an update is a solution to this but that is not applicable to the S140.

Is there a work around for this?

kind regards

Liam

[Susheel Nuguru]

Hi Liam,

on S140 the MCU is not blocked while using radio. So the application still has access to it apart from the pre and post processing it needs which can be seen in this diagram. As you can see that worst timing here that the softdevice steals MCU from APP is around 9uS and in your case your interrupt being masked for milliseconds does seem too much. How many milli seconds does it gets masked in worst case? Is it possible that some other high priority interrupt is masking your interrupt? Also what is the priority of your interrupt?

[Jordan Archer]

Is this still true?   And in what version of the SDK, on what parts?   And please update the link to the diagram.