Custom protocol - NRF_RADIO->EVENTS_END never called in reception (infinite loop)

[lbe]

Hi everyone,

I am implementing a custom protocol using the NRF52 radio, and so far I was able to make the transmitter working as expected.

In a nutshell, the protocol is based on carrier sensing, so every xx milliseconds the received reads the RSSI and if this is above a given threshold it means that a transmission is ongoing and it receives the packet. The problem is that when the reception is invoked, the received is stuck in the reception loop indefinitely. 

My code was based on the radio examples from the SDK, so the reception is essentially realized as follows

    NRF_RADIO->EVENTS_DISABLED = 0;
    NRF_RADIO->TASKS_DISABLE = 1;
    while(NRF_RADIO->EVENTS_DISABLED == 0);
    NRF_RADIO->EVENTS_READY = 0;
    NRF_RADIO->TASKS_RXEN = 1; 
    while (NRF_RADIO->EVENTS_READY == 0){}   //Wait while radio is ramping up.
        
    NRF_RADIO->PACKETPTR = (uint32_t)buf;

    NRF_RADIO->EVENTS_END = 0;
        // Start listening and wait for address received event
    NRF_RADIO->TASKS_START = 1;

    // Wait for end of packet or buttons state changed
    while (NRF_RADIO->EVENTS_END == 0)
        {
        // wait
        }

As said, my code is stuck in the last while loop. It is possible that the reception never happens (a wrong rssi detection, or a later switch to rx mode), but if this is the case will the radio stay in the loop forever? Isn't there a way to stop the reception after some time if no reception happens?

Thanks a lot for your help.

[Susheel Nuguru]

the code snippet you attached seems OK, not sure why there is no reception of data. I guess you need to sniff the packets in air to see if they are really packed as the receiver is expecting them or not.

[lbe]

Hello, thanks for your answer.

I fixed the issue there (not sure what was causing it, maybe a wrong setting in the packet length field....), but I still was unable to find an answer to the other two questions...

Let's assume that my device switches to RX mode, but for any reason a reception does not happen (interference, wrong RSSI measurement....). Is there a way to avoid that the device stays in the while loop forever waiting a transmission that will not come? Can I "release" the radio from its waiting state using some external event? (e.g. a timeout from an application timer or decrementing a counter).

[Susheel Nuguru]

Yes, you can use the event of the timer to trigger TASKS_DISABLE (using PPI) and the while loop can be modified as below

while ((NRF_RADIO->EVENTS_END == 0) && (NRF_RADIO->EVENTS_DISABLED == 0))
{
   // wait
}

[lbe]

Hello, 

thank you for your answer. I tried to use the PPI but I was unable to configure it correctly to perform the task you are suggesting.....I am not using the Timer to keep the consumption low, so my whole protocol uses the RTC clock......

It is not entirely clear to me how the PPI works, even if I saw the example code and the documentation....

could you point me in the right direction, or give a short snippet for the init part?

As said, what I need to achieve is that the radio goes in RX mode for xx milliseconds; after the xx milliseconds (measured using the RTC clock) passes, the radio stops listening for packets and the protocol resumes....

Thanks for your help!

[Susheel Nuguru]

It would be clearer if you provide me some code snippets of what you have done and tell me what did not work. I can then see if I can identify the problem and correct if there are any inaccuracies.