• State Verified Answer
  • Replies 2 replies
  • Subscribers 88 subscribers
  • Views 854 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 263694
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF Mesh: Premature end of timeslot causes delay of queued action in bearer_handler.c

m.wagner

Hello there,

Since we use the lower level modules from Nordic's SDK for Mesh 4.2.0 - namely timeslot.c, bearer_handler.c and some additional modules to make them work properly - I have stumbled upon an implementation detail in these modules, that I struggle to get my head around:

In bearer_handler.c, line 219, you'll find the following code:

if (p_action && (p_action->duration_us + BEARER_ACTION_POST_PROCESS_TIME_US) > total_time)
{
    /* The current timeslot doesn't have space for this action, restart the timeslot to get a longer one. */
    timeslot_restart(TIMESLOT_PRIORITY_HIGH);
}

This essentially results in populating the nrf_radio_request_t structure with these values:

m_radio_request_earliest.params.earliest.priority = NRF_RADIO_PRIORITY_HIGH;
m_radio_request_earliest.params.earliest.length_us = NRF_RADIO_LENGTH_MAX_US;
m_radio_request_earliest.params.earliest.timeout_us = NRF_RADIO_EARLIEST_TIMEOUT_MAX_US;

and ending the current timeslot prematurely by setting the corresponding return values for the radio signal handler:

p_timeslot->signal_ret_param.callback_action = NRF_RADIO_SIGNAL_CALLBACK_ACTION_REQUEST_AND_END;
p_timeslot->signal_ret_param.params.request.p_next = &m_radio_request_earliest;

From the comment in bearer_handler.c, I gather that the intention is to try and get a timeslot that has enough time for the requested action faster than normal.

What I noticed is that when this line of code is invoked with our application running as a BLE peripheral on Softdevice 7.2.0, having an active connection to a central, it actually takes longer until the next timeslot is started than without this line!

See the following trace:

I do not observe these ~50ms to ~80ms timeslot "outages" when I remove the invocation of timeslot_restart() at this point.

So my questions are:

  • Do you have an explanation for this behaviour?
  • Is this the indended behaviour?
  • Do I break something if I remove this line of code and if yes, what?
  • EDIT: I think I can imagine that removing this line can lead to crashes if actions are enqueued with a duration greater than e.g. the current connection interval or something like that. Is that possible?

Thanks for your advice & regards,

-mike

  • 0

    Hi,

    I have reached out to the team for help regarding your questions, I will update you as soon as I get a response from them.

    Thanks for your patience.

  • +1

    Hi,

    The team has looked into the issue and you are correct. This is intended behavior, a high priority timeslot is requested if an action doesn't fit in the current timeslot, to make sure that we fit in the next timeslot. This is typically flash related actions. The SD will then provide a timeslot at the earliest time, which might cause a delay, but ensures that the new timeslot will fit the action. Removing this line could cause some flash operations to stall indefinitely if they never fit within the current timeslot.

    Thank you for your patience.

Related