pipe info in nRF24L01+

[mike]

from the product spec NOTE: The 3 bit pipe information in the STATUS register is updated during the IRQ pin high to low transition. The pipe information is unreliable if the STATUS register is read during an IRQ pin high to low transition.

It has been mentioned several times in the forum to watch out for this, but the note doesn't make sense (to me). First if you mask the interrupts the IRQ will never change. What happens? Assuming the IRQs are not masked, but there are 2 messages in the RX fifo - After reading the first message at what does the pipe info in the status and length registers reflect the 2nd message, and how are you supposed to reliably read them (assuming you don't exit the interrupt routine)?

thanks mike

[Håkon Alseth]

Mike,

There are internal timings in the chip which may cause the STATUS register to give corrupt information when the IRQ pin is going from HIGH-to-LOW. The information is not valid until the pin is registered as a logic '0' on your MCU.

Best regards Håkon

[mike]

Håkon,

Somehow the replies seem out of sequence - not sure if I'm doing something wrong. Again thanks, for the response, but I'm still not sure. I want to use these devices in several projects, so I'm trying to understand how they work. Secondly I'm trying to understand if I am doing things right on my current project (which seems to work).

The processor in my current project is quite busy, so it is entirely possible that I receive a second packet while I am processing the first. Specifically I am using interrupts and my interrupt routine does

... while( RXFIFO not empty ) { pipe info <- read STATUS STATUS <- clear interrupt bit read message }

Is this correct? The interrupt pin will go H->L when the second packet arrives (it if arrives) does the interrupt occur before or after RX_EMPTY in FIFO_STATUS gets cleared? Will the STATUS register be correct or do I need to delay before reading it?

thanks mike

[Håkon Alseth]

Hi Mike,

If you have a scenario where your RX receives more interrupts while in the ISR, then you have a race condition. To handle this properly, you should check the FIFO_STATUS register to see if the RX FIFO still has entries in it (poll it). If you use ACKing, you will have at least ~150 us before the interrupt is asserted again as the PLL has 130 us turn-around time.

Note: If you fill up your RX_FIFO without reading out the payloads, then your RX will lock up until you flush the FIFO or read out at least one payload.

BR Håkon