pipe info in nRF24L01+

RE: pipe info in nRF24L01+

Håkon Alseth — Fri, 15 Nov 2013 09:24:52 GMT

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

RE: pipe info in nRF24L01+

mike — Fri, 15 Nov 2013 02:30:30 GMT

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

RE: pipe info in nRF24L01+

Håkon Alseth — Thu, 14 Nov 2013 20:06:02 GMT

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

RE: pipe info in nRF24L01+

mike — Tue, 12 Nov 2013 16:34:10 GMT

Håkon,

I understand the warning about the payload > 32.

My point was "fully implementing" the note about the STATUS register, which I can't do if I don't understand it.

mike

RE: pipe info in nRF24L01+

Håkon Alseth — Tue, 12 Nov 2013 15:32:11 GMT

Mike,

If this note is not fully implemented, you can be in a situation where you get corrupted info. This may give you garbage data.

You can lock up the state machine inside the radio-core if spec is not followed. An example of this is: A very important thing to always check if dynamic payload length is used, is the payload length. If you read out a payload of > 32 byte, then the state machine will go haywire and most likely lock up your receiver until power-cycle.

Best regards Håkon

RE: pipe info in nRF24L01+

mike — Tue, 12 Nov 2013 14:27:24 GMT

Håkon,

I think the penny just dropped. I suspect that the answer is that the STATUS register is not double buffered and so if the info is latched in the middle of reading the STATUS register the first bits output on the SPI interface will be the old info and the last bits will be the new info.

Since the bits are transmitted MSB first, by the time the RX_DR is asserted the RX_P_NO will be valid. There does seem to be an issue with TX_FULL as in this case, when the last location is transmitted, one could read the STATUS resgister and TX_DS could be set and TX_FULL could still be set. (TX_DS new info, TX_FULL old info), but I can't imagine any situation in which this would matter.

On the other hand the note (warning) is in the product spec (and was mentioned several times in this forum by Nordic employees), so I am still a little concerned there is more to this?

thanks Mike

RE: pipe info in nRF24L01+

mike — Tue, 12 Nov 2013 14:07:28 GMT

Håkon,

Thank you for your reply. It seems very, very strange that the act of asserting the IRQ pin would have an effect on the STATUS register?

In my second case (what is happening in my system) is that there are multiple messages in the RX queue, so even though I am using interrupts, I read the first message and then I read the status register to see if there is another message without exiting the interrupt routine. It is entirely possible that I am reading the STATUS exactly as the second (or third) IRQ is happening, but I am already in the interrupt handling routine. Then what happens?

RE: pipe info in nRF24L01+

Håkon Alseth — Tue, 12 Nov 2013 11:18:35 GMT

Hi Mike,

That note points to when the IRQ pin indicates an interrupt. If in that transaction, you read the STATUS register, the bits can not be reliable. What you then do is to ensure that the IRQ pin is properly asserted before reading the STATUS-register and clearing the interrupt cause (which will return the IRQ pin to high state).

Usually, this is not an issue, as it takes some time for the application MCU to register a pin-interrupt (us-range). At this time, every thing has stabilized, and you are safe to read the STATUS register.

If you do not enable the IRQ pin, meaning that you will do a polling sequence, this should not have an effect on your status-routine.

Best regards Håkon