Cleanup at timeslot end

[rgrr2]

Hi

if one searches the examples using the timeslot API, every application seems to do it's own timeslot cleanup.  Also documentation is not very clear about this.

Best/most confusing is nrf_raal_softdevice.c which does an exit with explicitly raising the radio interrupt (nrf_raal_continuous_mode_exit()).  I'm looking with some big question mark in my head at those __DMB()s.  Are they really required?

So my question: in what state RADIO/TIMER0/PPI etc should be left so that softdevice operation can continue correctly?

Thanks

Hardy

[Hung Bui]

Hi Hardy, 

If you want to test timeslot, I would suggest you to have a look here: https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/running-micro-esb-concurrently-with-ble

It's pretty old but the principle is the same. When you receive NRF_RADIO_CALLBACK_SIGNAL_TYPE_TIMER0 you have to stop the TIMER, RADIO etc. 
It's showed in the code above where TIMESLOT_END_IRQHandler() is called. 

I also attached here an example on SDK v15.0 . The radio is not used but you can find the TIMER being stopped in NRF_RADIO_CALLBACK_SIGNAL_TYPE_TIMER0 event in timeslot.c (the example is in \examples\ble_peripheral\ble_app_uart) 

nRF5_SDK_15.0.0_Timeslot.zip

[rgrr2]

Hi Hung Bui

thanks for the suggestion and examples.  I will have a closer look at those by tomorrow.

To me the thing which stings most in the eye is, that in the example the slot requests are done either as a result of the callback via NRF_RADIO_SIGNAL_CALLBACK_ACTION_REQUEST_AND_END or in the event handler thru sd_radio_requests().  Same method can be found e.g. in nrf_raal_softdevice.c

I think the above guarantees some synchronicity between BLE and the timeslot requester.

In our application the time of the next slot is not known / calculated at the end of the running slot.  So we have to use sd_radio_request() from user space after calculating the schedule.

Is this approach "legal" as well?  Or do we have to synchronize somehow BLE and our protocol to avoid race conditions inside the timeslot API?

I'm asking, because I'm experiencing random crashes inside the softdevice during concurrent operation.  One thing to check is/was how to leave timeslots in a tidy way.

So the question: do you have any hints, how the sd_radio_requests() should be done in a proper way?

Thanks & regards

Hardy

[rgrr2]

Hi Hung Bui

don't want to waste *your* time, but I'm already discussing an occuring failed assertion inside the softdevice in another thread with a colleague of you, see https://devzone.nordicsemi.com/f/nordic-q-a/58373/timeslots-and-softdevice-assertion-failed-pcxxx-0x2552e

My original idea of incorrect cleanup at end of timeslot seems to lead in the right direction: it has (hopefully) something to do with changed interrupt priorities of the radio.

Thanks for your support again.

Hardy