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

About reset_fifos() on the nrf_esb.c file

I have the following situation:

My device receives a number of RF packets, changes to TX mode, sends some data, goes back to RX mode and it should be able to access the received data that's on the RX FIFO.

But it is not able to access this data after the switch because every time it switch modes it calls nrf_esb_init() that calls the reset_fifos() function that sets all the FIFO's counters ( entry_point, exit_point, and count ) to zero.

Looking at the code looks like the data is actually never erased from the buffer after a reset. Just these counters are reset. The only way to lose the data is if it gets overwritten by an incoming packet.

So, I want to know if it is really necessary to reset all the counters of the RX FIFO after changing modes. I was wondering what kind of problems I can have if I just comment out the call to the function reset_fifos()

Thank you so much

Parents
  • Hi Jose

    If you don't use the ACK payload feature the RX FIFO should not be used in PTX mode, and vice versa, but the state machine in the library assumes that the FIFO's are empty after changing from one mode to the next. They are also tested under this assumption, and I wouldn't recommend changing this behavior unless you have no other options. 

    Is there any reason you can't read out any data in the FIFO before you change the mode?

    Best regards
    Torbjørn

  • We got a different approach. We are reading the incoming packet inside the IRQ of the RF sdk and storing it in our own custom buffer to process it later. We are a bit worried about the timing here, bcs we don't wanna spend too much time inside the IRQ. Do you see any potential problems with this solution?

  • Ho Jose

    You mean you are moving the data to the buffer inside the ESB callback?

    I don't think this should be an issue. If you are just doing a memcpy it should be relatively quick.

    Also, the ESB callback is running at a lower priority than the radio interrupt, to ensure that any processing you do in the callback won't block radio interrupts. 

    Best regards
    Torbjørn

Reply Children
No Data
Related