Softdevice event handler continuously called with NRF_EVT_RADIO_BLOCKED

RE: Softdevice event handler continuously called with NRF_EVT_RADIO_BLOCKED

Elfving — Wed, 27 Oct 2021 09:09:26 GMT

Hey Anne!

I'm glad this thread helped you out, and that you got help from Michael here as well. If you have further questions, it would be best if you started a new support ticket.

Best regards,

Elfving

RE: Softdevice event handler continuously called with NRF_EVT_RADIO_BLOCKED

Anne van Rossum — Mon, 18 Oct 2021 10:56:05 GMT

Ah, check! You're right of course. It's increasing `m_radio_request_earliest.params.earliest.timeout_us` what's recommended by Hung Bui here.

We see this also with `NRF_SDH_BLE_GAP_EVENT_LENGTH` of size `6` by the way, but not with every connection set up.

Reported at devzone.nordicsemi.com/.../scheduler-get-full-by-nrf_evt_radio_blocked-events-during-connect so let's see what's the best way to handle this.

RE: Softdevice event handler continuously called with NRF_EVT_RADIO_BLOCKED

m.wagner — Mon, 18 Oct 2021 05:41:13 GMT

Hi Anne,

I don't think Nordic employees get notified of responses to questions with verified answers.

But just note that we were talking about increasing the timeout, not the length. Reducing the length is the right thing to do. Increasing the timeout will lead to reduced timeslot availbility - as evident from the above discussion. So if you want to optimise for timeslot uptime you've got to live with the above scheduler behaviour.

Regards

RE: Softdevice event handler continuously called with NRF_EVT_RADIO_BLOCKED

Anne van Rossum — Tue, 12 Oct 2021 14:57:13 GMT

If (dynamically) increasing m_radio_request_earliest.params.earliest.length_us is what you recommend when getting NRF_EVT_RADIO_BLOCKED in the Mesh code (https://github.com/NordicSemiconductor/nRF5-SDK-for-Mesh/blob/master/mesh/core/src/timeslot.c#L419), then shouldn't this be implemented?

Everybody who sets up connections will run into this. And not always in a very pleasant way, it's namely the case that sd_radio_request() uses the app scheduler which can run out of space.

RE: Softdevice event handler continuously called with NRF_EVT_RADIO_BLOCKED

Hung Bui — Fri, 26 Feb 2021 13:01:13 GMT

I'm happy to help :) it's an interesting topic to look into :)

RE: Softdevice event handler continuously called with NRF_EVT_RADIO_BLOCKED

m.wagner — Thu, 25 Feb 2021 15:54:33 GMT

[quote userid="2121" url="~/f/nordic-q-a/71360/softdevice-event-handler-continuously-called-with-nrf_evt_radio_blocked/296345#296345"]I assume when you mentioned "large event_length". it's just larger than 6 and still not larger than the connection interval ? [/quote]

By this I actually only meant that the softdevice is configured with a value for NRF_SDH_BLE_GAP_EVENT_LENGTH that is larger than 6.

[quote userid="2121" url="~/f/nordic-q-a/71360/softdevice-event-handler-continuously-called-with-nrf_evt_radio_blocked/296345#296345"]
As far as I know when event_length is larger than connection interval it will not take effect and will be capped at the connection interval as the max value.[/quote]

Okay, that makes sense - I did not take this limit into account.

[quote userid="2121" url="~/f/nordic-q-a/71360/softdevice-event-handler-continuously-called-with-nrf_evt_radio_blocked/296345#296345"]When you mentioned "potential max" , did you mean the event_length ?
The softdevice should always presume that the connection event will last as long as event_length. [/quote]

If by "event_length" you mean NRF_SDH_BLE_GAP_EVENT_LENGTH, then yes, that is wath I meant.

[quote userid="2121" url="~/f/nordic-q-a/71360/softdevice-event-handler-continuously-called-with-nrf_evt_radio_blocked/296345#296345"]To save power consumption of the peripheral and to avoid the timeslot being blocked by short conn interval, you can use slave latency.[/quote]

Yes, we already try to use slave latency if possible. Since the connection interval is essentially given by our peer (running as peripheral only), I don't want to rely on the connection interval too much.

[quote userid="2121" url="~/f/nordic-q-a/71360/softdevice-event-handler-continuously-called-with-nrf_evt_radio_blocked/296345#296345"]
In your case when you want the timeslot as much as possible, power consumption may not be a big problem. Then you can afford to go with the approach to request continuously, I think that would be a good workaround for the "non-dynamic" scheduler. [/quote]

I think that's the way to go here. All measurements and our discussion here point to this being the ideal solution for our application.

Thanks for your help!

Regards,

-mike

RE: Softdevice event handler continuously called with NRF_EVT_RADIO_BLOCKED

Hung Bui — Thu, 25 Feb 2021 15:44:17 GMT

Hi Mike,
I assume when you mentioned "large event_length". it's just larger than 6 and still not larger than the connection interval ?
As far as I know when event_length is larger than connection interval it will not take effect and will be capped at the connection interval as the max value.

When you mentioned "potential max" , did you mean the event_length ?
The softdevice should always presume that the connection event will last as long as event_length.

Our softdevice scheduler is not designed to be able to re-schedule if the connection event ends earlier than expected (which is the event_length). This requires a more dynamic algorithm for scheduling and complicating thing a little bit.

If you want to avoid such down time, I would suggest to use shorter connection interval. To save power consumption of the peripheral and to avoid the timeslot being blocked by short conn interval, you can use slave latency. When the slave skips the connection events due to slave latency, the timeslots can take place in those slots.

In your case when you want the timeslot as much as possible, power consumption may not be a big problem. Then you can afford to go with the approach to request continuously, I think that would be a good workaround for the "non-dynamic" scheduler.

RE: Softdevice event handler continuously called with NRF_EVT_RADIO_BLOCKED

m.wagner — Thu, 25 Feb 2021 15:14:50 GMT

Hi Hung Bui,

Thanks for the explanation. Even though, you did not touch on the impact of NRF_SDH_BLE_GAP_EVENT_LENGTH, I think it helped me understand what actually happens here.

Just for clarification: I do observe this behaviour (continuous BLOCKED loop) during each and every connection event - not just during connection establishement.

To sum up the issue again:

My issue was that I discovered this loop of NRF_EVT_RADIO_BLOCKED.
This behaviour can be modified by changing the parameters of the request - most notably increasing the timeout leads to fewer or even none of these BLOCKED events.
This however will often result in larger "downtime" of the timeslot

In a "normal" scenario where NRF_SDH_BLE_GAP_EVENT_LENGTH is at the default of 6, a rather low timeout value of 15000us will most likely not result in a BLOCKED timeslot or at least not often. The example above illustrates the scenario where it is BLOCKED once, but then the requested timeslot can be scheduled after the Connection event ends...

The above sketch illustrates a scenario with a large GAP event length but still a short timeout. With NRF_SDH_BLE_GAP_EVENT_LENGTH set to a larger value - let's assume the maximum value of 320 as used in my application - the Softdevice does not yet know how long a connection event will be at the time it is scheduled. Therefore it has to assume the maximum length of 400ms.

So radio requests with a short timeout will be continuously blocked until either the timeout at the point of the request is long enough to be after the potential maximum event duration or the connection event actually ended and the Softdevice can grant the timeslot immediately.

To circumvent this, one may be tempted to increase the timeout. If we increase the timeout to a value > 400000us (greater than the maximum connection event duration), we get the following scenario:

The timeout is longer, so the softdevice just schedules the next timeslot at the first point after the potential max. duration of the connection event. In our example this would be about 400ms after the connection event started. But the connection event may actually be over in as little as 7.5ms and therefore, we have 392.5ms of unnecessary downtime of the timeslot!

Hung Bui Can you confirm that I got this right?

[quote userid="2121" url="~/f/nordic-q-a/71360/softdevice-event-handler-continuously-called-with-nrf_evt_radio_blocked/296180#296180"]To avoid this loop what we usually do is to gradually increase the timeout_us when we receive the repeated blocked events (in crease it by 1ms each for example). This way we can still get the earliest possible timeslot when the higher priority activity passed.[/quote]

I played around with this, but what essentially happens with a large value for NRF_SDH_BLE_GAP_EVENT_LENGTH is that I increase the timeout and in the best case scenario, there is still a loop of calls to the softdevice event handler and in the worst case scenario, at some point the timeouts were large enough to still get a timeslot scheduled but after an unnecessary delay.

So as it stands right now, I think I would prefer the continuous calls to the SD event handler with the BLOCKED signal to having gaps in radio availability in the timeslot.

It would be nice if the softdevice could either reschedule a timeslot if it notices that there is a gap of "wasted" time or if there was any other way to avoid this loop (e.g. an event indicating that a connection event passed - at which point it would be possible to manualy request a new timeslot?)

Do you have any suggestions?

Thanks & best regards,

-mike

RE: Softdevice event handler continuously called with NRF_EVT_RADIO_BLOCKED

Hung Bui — Thu, 25 Feb 2021 09:41:00 GMT

Hi Mike,

I think I can explain the reason you get continuous blocking event with such configuration.

When you change the timeout to 15ms and when you just enter a connection, the first connection event has more priority than timeslot at HIGH. The first connection event(s) is important because if you miss 6 of them the connection will be terminated.

So timeslot will be blocked at least for the period of the first connection event (7.5ms + t_dist ) period, it will hit the 15ms timeout and the request for earliest timeslot will be blocked.

Then the code will receive NRF_EVT_RADIO_BLOCKED event, it will then immediately request a new request_next_event_earliest() which will also result in NRF_EVT_RADIO_BLOCKED because the timeout it still inside the period occupied by the first connection event. And this loop continues until the timeout 15ms it out of the period occupied by the first connection event (in my case with connection interval of 7.5ms it took 2ms of continously trying to get the timeslot.

To avoid this loop what we usually do is to gradually increase the timeout_us when we receive the repeated blocked events (in crease it by 1ms each for example). This way we can still get the earliest possible timeslot when the higher priority activity passed.

RE: Softdevice event handler continuously called with NRF_EVT_RADIO_BLOCKED

m.wagner — Wed, 24 Feb 2021 16:10:44 GMT

Hi Hung Bui

[quote userid="2121" url="~/f/nordic-q-a/71360/softdevice-event-handler-continuously-called-with-nrf_evt_radio_blocked/294180#294180"]This bug only affect central devices in some corner cases. [/quote][quote userid="2121" url="~/f/nordic-q-a/71360/softdevice-event-handler-continuously-called-with-nrf_evt_radio_blocked/294180#294180"]I believe the draw back is actually the timing needed to start the crystal, not really about that the HFCLK is kept between timeslot and BLE activity (actually it's the opposite, when you use NRF_RADIO_HFCLK_CFG_XTAL_GUARANTEED the clock is kept)[/quote]

Okay, that's helpful. In conclusion, I know now that I'm safe and better off to use NRF_RADIO_HFCLK_CFG_XTAL_GUARANTEED in my application.

[quote userid="2121" url="~/f/nordic-q-a/71360/softdevice-event-handler-continuously-called-with-nrf_evt_radio_blocked/294180#294180"]What I'm not really certain about is why in your case the softdevice doesn't grant the timeslot when the interval is 7.5ms when in my example it works fine.[/quote]

I think we were talking about different things here. When I originally wrote that setting the priority to HIGH does not change the oserved behaviour, I was referring to the continuous indications of the BLOCKED event. This still occurs when setting the priority to HIGH, but I will manage to get a timeslot within reasonable time.

[quote userid="2121" url="~/f/nordic-q-a/71360/softdevice-event-handler-continuously-called-with-nrf_evt_radio_blocked/293842#293842"]But if you can reproduce on much simpler application then it's easier to spot the root cause. [/quote]

I managed to reproduce the behaviour where the signal handler is continuously invoked with the BLOCKED event with your example. It happens as soon as I reduce the timeout_us parameter to e.g. 15000 while also configuring the softdevice with any value for NRF_SDH_BLE_GAP_EVENT_LENGTH greater than 6. The higher the value, the more subsequent BLOCKED events seem to occur.

Steps to reproduce with your example:

Get the linked example to run as per the instructions.
Attach the patch attached to this comment
Run the example
Connect a BLE central to the peripheral (advertising as "Nordic_UART"). I used the Desktop version of nRF Connect.

This will result in the BLOCKED event being continuously invoked as soon as a timeslot ends.

The patch contains the following changes:

Added and enabled GPIOs for debugging:
- P0.03 - Signals whether device is in timeslot
- P0.04 - High while in radio callback (signal ID is indicated by repeated toggles)
- P0.28 - Set when callback_action set to NRF_RADIO_SIGNAL_CALLBACK_ACTION_EXTEND, cleared on EXTEND_SUCCEEDED or EXTEND_FAILED
- P0.29 - High while serving SIGNAL_TYPE_TIMER0
- P0.30 - High while in softdevice signal handler (signal ID is indicated by repeated toggles)
- P0.31 - High while serving TIMER0 interrupt where timeslot is ended.
- P0.25 - Indicates EXTEND_SUCCEEDED.
Reduced the timeout_us parameter in the radio request to 15000.
Increased NRF_SDH_BLE_GAP_EVENT_LENGTH to 7.
Increased RAM available for Softdevice (so NRF_SDH_BLE_GAP_EVENT_LENGTH can be increased up to 320)

devzone.nordicsemi.com/.../4314.example_2D00_uart_2D00_esb_2D00_timeslot.patch

It would be great if you can look into this and find a solution to this erroneous behaviour.

Thanks & best regards,

-mike

RE: Softdevice event handler continuously called with NRF_EVT_RADIO_BLOCKED

Hung Bui — Fri, 12 Feb 2021 14:04:34 GMT

Hi Michael,

I talked to Sigurd, the bug that the central couldn't send the the first connection event is fixed from Softdevice v8. However we haven't released the S132/S140 v8.0 yet.

This bug only affect central devices in some corner cases.

I believe the draw back is actually the timing needed to start the crystal, not really about that the HFCLK is kept between timeslot and BLE activity (actually it's the opposite, when you use NRF_RADIO_HFCLK_CFG_XTAL_GUARANTEED the clock is kept)

What I'm not really certain about is why in your case the softdevice doesn't grant the timeslot when the interval is 7.5ms when in my example it works fine. In my example, the connection event and the timeslot take turn to preempt each other resulting a timeslot in every 15ms, this match with what described in the timeslot priority that when set to HIGH it has the same priority as the connection event.

I would suggest you to double check if you have selected the timeslot priority to HIGH in the request after it's blocked.

RE: Softdevice event handler continuously called with NRF_EVT_RADIO_BLOCKED

m.wagner — Thu, 11 Feb 2021 09:31:21 GMT

Hi Hung Bui,

[quote userid="2121" url="~/f/nordic-q-a/71360/softdevice-event-handler-continuously-called-with-nrf_evt_radio_blocked/293842#293842"]I think the softdevice always assume the crystal is disabled when it's returned from the application timeslot. So it's the application responsibility to disable it again before timeslot ends.[/quote]

Okay, I think you helped me understand it better. I was thrown off by the Nordic engineers response to the issue I linked above. The suggested workaround there was:

[quote userid="15146" url="~/f/nordic-q-a/55264/nus-connection-problems-with-timesync-example-ported-to-sdk16-0-0/232503#232503"]Based on initial testing, it's seems like using NRF_RADIO_HFCLK_CFG_XTAL_GUARANTEED is causing the first packet sent by the master after CONNECT_IND packet to be sent a bit too early. Other workarounds could be to set NRF_SDH_CLOCK_LF_ACCURACY to 1, or use NRF_RADIO_HFCLK_CFG_NO_GUARANTEE. [/quote]

The user then asked whether there are any negative impacts:

[quote userid="85765" url="~/f/nordic-q-a/55264/nus-connection-problems-with-timesync-example-ported-to-sdk16-0-0/234049#234049"]In the time_sync example HFCLK is alway on due to calling sd_clock_hfclk_request(). So if I change the timeslot requests from NRF_RADIO_HFCLK_CFG_XTAL_GUARANTEED to NRF_RADIO_HFCLK_CFG_NO_GUARANTEE are there any drawbacks?[/quote]

And the engineers response was:

[quote userid="15146" url="~/f/nordic-q-a/55264/nus-connection-problems-with-timesync-example-ported-to-sdk16-0-0/234240#234240"]Only that the HFCLK is not turned off between BLE radio and timeslot usage, so the current consumption will potentially be a little bit higher.[/quote]

So I assumed that it is not actually required that the HFCLK must be disabled before ending the timeslot.

I could imagine, though, that the root of my issue with the softdevice not granting any timeslots with a 7.5ms connection interval, is that the softdevice's scheduling needs to account for the time it takes for the hfclk to start - no matter if it's already running or not - and therefore does not grant any timeslots in this scenario. Can you confirm this?

Does the softdevice issue above actually have any impact on a device that only implements a BLE peripheral?

Of course. I thought it may already be helpful since it's a slight modification to one of the Mesh SDK example.

I'm still working on reproducing it with your example, but so far without success. It looks like I managed to trigger the behaviour I observed in my other open issue pertaining to timeslots, where it seems the softdevice does not fire the signal handler for TIMER0 interrupts and then fires the event handler with NRF_EVT_RADIO_IDLE even though the timeslot was not ended via signal handler. Will post these findings to the other issue when I'm ready.

RE: Softdevice event handler continuously called with NRF_EVT_RADIO_BLOCKED

Hung Bui — Wed, 10 Feb 2021 16:30:59 GMT

Hi Michael,

I quote here what inside the Softdevice spec :

I think the softdevice always assume the crystal is disabled when it's returned from the application timeslot. So it's the application responsibility to disable it again before timeslot ends.

I understood that you have a working example that only have some corner cases need to be fixed. But if you can reproduce on much simpler application then it's easier to spot the root cause.

RE: Softdevice event handler continuously called with NRF_EVT_RADIO_BLOCKED

m.wagner — Wed, 10 Feb 2021 14:57:18 GMT

Hi Hung Bui,

[quote userid="2121" url="~/f/nordic-q-a/71360/softdevice-event-handler-continuously-called-with-nrf_evt_radio_blocked/293805#293805"]When you use NRF_RADIO_HFCLK_CFG_NO_GUARANTEE, you have the responsibility to disable the crystal before the timeslot end.[/quote]

I'm not sure it would be of much use to try our application with your example, since we use the entire timeslot extension algorithm from Nordic's Mesh stack - which apart from these few open issues I have - works really well and allows us to absolutely maximise timeslot use...

Why would I need to disable it? Can't I leave it running for the entire run time of my application?

[quote userid="2121" url="~/f/nordic-q-a/71360/softdevice-event-handler-continuously-called-with-nrf_evt_radio_blocked/293805#293805"]
Regarding issue #1 if you can find away to reproduce with my example code on github above, I can try to test here. [/quote]

Would be great if you could take a look at the mesh example I provided above. It's almost out of the box, the only modifications I did were the required path adaptations and setting NRF_SDH_BLE_GAP_EVENT_LENGTH to 320.

I'll see if I manage to reproduce it with your example, though.

Thanks & regards,

-mike

RE: Softdevice event handler continuously called with NRF_EVT_RADIO_BLOCKED

Hung Bui — Wed, 10 Feb 2021 14:44:24 GMT

Hi Michael,

I tried this configuration:

#define TS_LEN_US                   (5000UL)                /**< Length of timeslot to be requested. */
#define TX_LEN_EXTENSION_US         (5000UL)                /**< Length of timeslot to be extended. */
#define TS_SAFETY_MARGIN_US         (700UL)                 /**< The timeslot activity should be finished with this much to spare. */
#define TS_EXTEND_MARGIN_US         (2000UL)                /**< Margin reserved for extension processing. */

uint32_t request_next_event_earliest(void)
{
    m_timeslot_request.request_type                = NRF_RADIO_REQ_TYPE_EARLIEST;
    m_timeslot_request.params.earliest.hfclk       = NRF_RADIO_HFCLK_CFG_NO_GUARANTEE;
    m_timeslot_request.params.earliest.priority    = NRF_RADIO_PRIORITY_HIGH;
    m_timeslot_request.params.earliest.length_us   = TS_LEN_US;
    m_timeslot_request.params.earliest.timeout_us  = 500000;
    return sd_radio_request(&m_timeslot_request);
}


/**@brief Configure next timeslot event in earliest configuration.
 */
void configure_next_event_earliest(void)
{
    m_timeslot_request.request_type                = NRF_RADIO_REQ_TYPE_EARLIEST;
    m_timeslot_request.params.earliest.hfclk       = NRF_RADIO_HFCLK_CFG_NO_GUARANTEE;
    m_timeslot_request.params.earliest.priority    = NRF_RADIO_PRIORITY_HIGH;
    m_timeslot_request.params.earliest.length_us   = TS_LEN_US;
    m_timeslot_request.params.earliest.timeout_us  = 500000;
}

And it doesn't seem to get any problem with 7.5ms. The timeslot is granted every other connection event.

You can try my code here. please update with the above configuration.

When you use NRF_RADIO_HFCLK_CFG_NO_GUARANTEE, you have the responsibility to disable the crystal before the timeslot end. And the softdevice would need to start it again when it get back to BLE activity. So it may take longer time for the softdevice to ramp up the radio before it can handle the BLE activity. But in my case this anyway doesn't seem to affect the timeslot request. You can find attached trace which i used the NRF_RADIO_HFCLK_CFG_NO_GUARANTEE with 7.5ms interval.
devzone.nordicsemi.com/.../10Feb.zip

Regarding issue #1 if you can find away to reproduce with my example code on github above, I can try to test here.

RE: Softdevice event handler continuously called with NRF_EVT_RADIO_BLOCKED

m.wagner — Tue, 09 Feb 2021 13:52:33 GMT

In the meantime, I was able to reproduce the issue with the ble_app_proximity example from the nRF SDK for Mesh 4.2.0.

I've attached the diff to the nRF SDK for Mesh 4.2.0 folder. The modifications I made were:

Modified nRF5 SDK related paths in project file to point to folder nRF5_SDK at same level as the mesh SDK folder is.
Enabled and configured timeslot debug pins (default configuration for timeslot debugging in mesh/core):
- P0.03: high while in timeslot
- P0.04: high while in signal handler
- P0.28: high while trying to extend timeslot
- P0.29: high when serving TIMER0 IRQ
- P0.30: high while in softdevice event handler (the culprit here!)
- P0.31: High when timeslot end is reached
- P0.24: High if high priority timeslot was requested
- P0.25: High if extension succeeded.
Set APP_TIMER_CONFIG_RTC_FREQUENCY to 0 (only way the example runs)
Set NRF_SDH_BLE_GAP_EVENT_LENGTH to 320 --> this triggers the issue!

devzone.nordicsemi.com/.../timeslot_2D00_sd_2D00_event_2D00_loop.patch

So I've touched on two issues here:

The weird behaviour (described in the initial post) that occurs during a BLE connection where the SD event handler is invoked repeatedly. This seems to happen in the suppleid exemple when settting NRF_SDH_BLE_GAP_EVENT_LENGTH to 320. We set this to a high value to be able to achieve higher BLE throughput when needed.

Do you have any explanation as to why this behaviour occurs and how it can be avoided?
When setting the hfclk parameter to NRF_RADIO_HFCLK_CFG_NO_GUARANTEE, no timeslots can be served if the connection interval is only 7.5ms. The idea was to configure the hfclk that way because we are able to have it continuously running, as we do not have any battery constraints. Additionally, there seems to be a connection issue that seems to be avoidable if NRF_RADIO_HFCLK_CFG_NO_GUARANTEE is chosen.

So why can no timeslots be served with a 7.5ms connection interval and NRF_RADIO_HFCLK_CFG_NO_GUARANTEE even though the HFCLK is running?

Looking forward to your responses!

Thank you & best regards,

-mike

RE: Softdevice event handler continuously called with NRF_EVT_RADIO_BLOCKED

m.wagner — Tue, 09 Feb 2021 10:58:44 GMT

Hi Hung Bui,

Thank you for your response.

[quote userid="2121" url="~/f/nordic-q-a/71360/softdevice-event-handler-continuously-called-with-nrf_evt_radio_blocked/293377#293377"]According to this if you request the timeslot at NORMAL priority it will have lower priority than the connection activity, meaning that if the timeslot doesn't fit entirely inside a period when there is no connection event (calculated by the event length reserved) it will get cancelled. [/quote]

I was aware of the above table, thanks. I think you helped me understand the difference between BLOCKED and CANCELED better, still, could you confirm that I got this right:

BLOCKED: the request with sd_radio_request() or via return value of the signal callback could not be granted within the provided timeout?
CANCELED: the softdevice originally intended to grant the requested timeslot - i.e. but at the point where it should have started, it could not grant it because an event of higher priority (e.g. BLE event when timeslot priority is normal) needs to be served during the timeslot.

So that means from the callers perspective what happens is actually similar, but the two events are raised at different "stages" in the softdevice's scheduling.

Is this right?

[quote userid="2121" url="~/f/nordic-q-a/71360/softdevice-event-handler-continuously-called-with-nrf_evt_radio_blocked/293377#293377"]Please try to test again with the priority set to HIGH. [/quote]

This does not change the observed behaviour.

[quote userid="2121" url="~/f/nordic-q-a/71360/softdevice-event-handler-continuously-called-with-nrf_evt_radio_blocked/293377#293377"]However, I couldn't explain why you get the event every 50us. We may need to look into your code to see why. [/quote]

"My code" for the timeslot implementation is actually the timeslot.c implementation from nRF SDK for Mesh 4.2.0.

I did just play around with examples\sdk_coexist\ble_app_proximity_coexist in the nRF SDK for Mesh 4.2.0 and stumbled upon one change that I made that seems to be the cause of all my issues:

Because we usually have the HFCLK running, I changed the hfclk parameter in the radio request to NRF_RADIO_HFCLK_CFG_NO_GUARANTEE. The change was prompted because I was afraid, that we could run into the issue described here. Therefore I implemented this as a temporary workaround.

With the hfclk parameter set to NRF_RADIO_HFCLK_CFG_NO_GUARANTEE, the softdevice stops granting me timeslots when the connection interval is only 7.5ms. This is the behaviour I observed and described above and I followed this by changing the requests. But I could not reproduce the behaviour with the continuous calls of the softdevice event handler - even when updating to S132 7.2.0.

So, maybe there is still something in our application that somehow interferes. Unfortunately I can't publicly share the application's source code here.

RE: Softdevice event handler continuously called with NRF_EVT_RADIO_BLOCKED

Hung Bui — Mon, 08 Feb 2021 15:02:39 GMT

Hi Michael,
If you have a look at the documentation of the softdevice (SDS) you can find this scheduling properties:

According to this if you request the timeslot at NORMAL priority it will have lower priority than the connection activity, meaning that if the timeslot doesn't fit entirely inside a period when there is no connection event (calculated by the event length reserved) it will get cancelled.

Please try to test again with the priority set to HIGH.

However, I couldn't explain why you get the event every 50us. We may need to look into your code to see why.

You can have a look at my example code here.

I attached the logic trace in my test here when the device first advertised, then entered a connection with interval = 7.5ms after 5 seconds the interval changed to 750ms. You can find the timeslot got cancelled multiple times, but still it get some slots in between.

devzone.nordicsemi.com/.../1-MHz_2C00_-20-M-Samples-_5B00_9_5D00_.logicdata