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

[zjw2021]

Hi Hung Bui

   The project is already using mesh stack.

   At present, it is necessary to capture the time of each pulse width in a signal with a length of 2ms in real time. So my current idea is to use ppi to trigger timer capture. And let the CPU record the capture time. But because mesh will preempt the interrupt. result in the loss of a pulse, which is unacceptable in this project.

  So I was wondering if I could use timeslot to ensure that when a pulse comes over, I can completely capture this pulse.

[Hung Bui]

Hi Zjw, 

If you simply want to capture the actual length of a pulse, aren't the PPI captures enough ? 
The CPU doesn't need to run in real time to calculate the distance between two capture registers ? 

I'm not so sure I understand what you meant by "CPU record the capture time" and by "mesh will preempt the interrupt" . 
As far as I know mesh shouldn't preempt the PPI that trigger the capture task. 

[zjw2021]

Hi Hung Bui

     Usually 48 pulses need to be captured in one signal. The duration of each pulse needs to be captured (the pulse width is about 47 μs).

     If using PPI can only capture the time of one of the pulses. Then the timer interrupt saves the capture to the array.

    Sometimes the BLE interrupt will cause the timer interrupt to hang, and one of the rising or falling edges is not captured. So I want to use the timeslot function to ensure that the entire pulse signal received is complete.

[Hung Bui]

Hi Zjw, 

Thanks for the info. let me sum up, so you have about 48 pulses, each can have a width up to 47us. And the whole thing may last about 2ms. 

How often do the pulses come ? Can you choose when to receive them or they comes periodically or they don't have any interval ? 

If they don't have an interval and if you don't have control over when you receive them, I am not sure the timeslot could even help here, because it would take some time to request the softdevice to allow the timeslot to start. 

Would it be possible that you can pause mesh (and BLE ? ) for a short period to receive the pulse and then enable mesh again ?