This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Cleanup at timeslot end

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

Parents
  • 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

  • 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

Reply
  • 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

Children
No Data
Related