Trigger radio signal in multiprotocol.

[Max Sikström]

We are implementing a protocol using the softdevice s140 multiprotocol API. The protocol is always listening, but occasionally transmitting.

To manage this setup, we request timeslots of a configurable interval (for example 30ms), and have set TIMER0 to wake up after a shorter time (for example 25ms) to trigger a signal and request an extend to continue listen, for example from now+30ms.

This works quite fine, and we can manage to always listen, and from time to time be interrupted for BLE traffic.

The question is about TX, or more specifically how to interrupt the RX.f

When the application want to transmit a packet, we don't want the system to wait for the TIMER0 interrupt to be able to handle the transmission from the radio signals, but rather get another signal immediately, that have the possibility to send back actions like extend. But more importantly on the same interrupt level to make it easier to manage concurrency to the memory.

So the question:

Is it possible to from thread level/application trigger a signal in the time slot in the multiprotocol api?

I was thinking if it would be possible to use NVIC_SetPendingIRQ(RADIO_IRQn); but is not sure if that would be supported or have side effects, for example if it would happen outside of a time slot

[Max Sikström]

Hi,

Looking at the SoftDevice Specificataion for s140, there is a section Radio Timeslot Signals (in PDF version v2.1, numbered 9.2.7.3), For example signal NRF_RADIO_CALLBACK_SIGNAL_TYPE_RADIO and NRF_RADIO_CALLBACK_SIGNAL_TYPE_TIMER0

infocenter.nordicsemi.com/.../tsl_signals.html

Those signals area to be received like interrupts on highest priority by the application, and works much like interrupts. But the difference are that they return an action.

The signal handler is specified with the sd_radio_session_open():

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.s140.api.v7.2.0%2Fgroup___n_r_f___s_o_c___f_u_n_c_t_i_o_n_s.html&anchor=ga55a52eb4d0491cb7105de6a13eb2b11b

The signals referred to is handled by the callback of type nrf_signal_callback_t, and is able to return an action defined by the type nrf_radio_signal_callback_return_parameter_t.

One scenario would be that if we have a slot requested for 5 more milliseconds, and still are listening, to be able to transmit we might need to do CCA, transmit, and then wait for an acknowledgement. If we don't have time for that, it's not worth starting the transmission. So in our case, the interrupt needs to be able to first try to extend, and if successful, transmit.

Thus, just triggering another IRQ won't give access to slot extend (or other return actions) to update the slot. So just access the radio would not be enough, since then we might break the requirement that all radio operations must be finished before the slot ends.

[Hung Bui]

Hi again Max, 

So it's more about extending a timeslot dynamically ? If that's the case, it's pretty easy. Currently we trigger a extending request by setting a TIMER0 interrupt. In our case it's NRF_TIMER0->EVENTS_COMPARE[1] event. When this even is triggered the softdevice will signal NRF_RADIO_CALLBACK_SIGNAL_TYPE_TIMER0 and you can return your request to extend there. 

I haven't tried by I think you can just trigger the TIMER0 interrupt by calling NVIC_SetPendingIRQ(TIMER0_IRQn). If that's not allowed by the softdevice you  can just setup a CC[] register to trigger a EVENT_COMPARE. You have mutliple CC registers to trigger different COMPARE events. You can use a TASK_CAPTURE to get the current timer counter and can trigger an event right away.