timeslot parameter setting and softdevice hang

[zjw2021]

Hi:

   when i set the timeslot parameter see below:I found it will run.However, after running for a few seconds, the program hangs. Debugging found that the softdevice hangs.(see the picture below).

my questions is:

1.why the "timeout_us"  parameter setting is too small, the program will hang instead of reporting an error state and let the program continue？

2.For app code that needs to be executed during a timeslot session, is there any requirement to put it in which function. My understanding is: as long as it is judged that the "NRF_RADIO_CALLBACK_SIGNAL_TYPE_START" signal is triggered, a global variable can be set, and my app will monitor this global variable. If the global variable is set, my program will be executed immediately.

3.If there is BLE network communication during the request timeslot (for example, I request a 100ms timeslot), will BLE data packets be lost at this time？

void configure_next_event_earliest(void)
{
    m_slot_length                                  = 80000;
    m_timeslot_request.request_type                = NRF_RADIO_REQ_TYPE_EARLIEST;
    m_timeslot_request.params.earliest.hfclk       = NRF_RADIO_HFCLK_CFG_XTAL_GUARANTEED;
    m_timeslot_request.params.earliest.priority    = NRF_RADIO_PRIORITY_HIGH;
    m_timeslot_request.params.earliest.length_us   = m_slot_length;
    m_timeslot_request.params.earliest.timeout_us  = 10000*100;
}

my SDK:15.0.0

softdevice:S132

IC:nrf52832

[Hung Bui]

Hi Zjw, 

I would suggest to have a look at the blog here and the source code here. It's an example of how to use the radio timeslot to do ESB protocol. 

Regarding your question: 

1. I'm not so sure what you showed in the screenshot meant that the softdevice hang. It can be a hardfault from the softdevice not "hang". Which  timeout_us did you use ? Did you base your implementation on one of our example ? 

2. The way we do it is to trigger a lower priority interrupt when we receive NRF_RADIO_CALLBACK_SIGNAL_TYPE_START event. Like in the example I pointed to we trigger TIMESLOT_BEGIN_IRQn. This way we don't need to have a loop in the main loop to wait for the global variable to change. 

3. Please have a look at chapter 15 Scheduling in the S132 v7.0 specification: 

The role that has higher priority can preempt the role that has lower priority. If they are at the same priority and if the timeslot has already secured the slot with the scheduler , the BLE event will be dropped. However, it doesn't mean the BLE packet will be lost. By design, BLE packets will be retransmitted if it's not ACKed by the other side. So there will be latency introduced by the 100ms timeslot, but data will be retransmitted afterward.