nRF24L01P PRX TX FIFO

[RAB]

I am coming across a strange issue with a nRF24L01P running enhanced shockburst. I have 1 PRX and a few PTXs communicating in a star network. The type of PTX determines which datapipe is used on the PRX. All PTXs use their datapipe 0 for the auto ACK function. The PRX assigns a datapipe address and channel to a PTX during the pairing process. The PRX either assigns datapipe 1 to a certain type of PTX or it assigns datapipe 2 to all other PTX types. The PRX doesn't use datapipe 0 because he can actually switch to a PTX and transmit data if needed so datapipe 0 is used to support the auto ACK function in this case too. Everything has been working great for over a year with several hundred systems deployed in the field.

Now we are looking to do some new things. I would like to have the PRX attach a payload to the ACK packet that is sent back to the PTX that exclusively uses datapipe 1. This payload would tell the PTX to transmit his payload again. Thus forming a feedback loop of sorts. The PRX is expecting a transmission from the PTX so he preloads the dynamic payload into the TX FIFO for datapipe 1. When the PTX transmits his payload he checks to see if there is an attached payload to the ACK. If there is a payload and it is the correct flag, then the PTX will transmit again the next 100ms cycle. This continues until the PRX stops attaching a payload to the ACK based on an external input to the PRX.

Everything works fine on the bench but when applied to an actual test case the PRX seems to lock up at random times. In this lock up case the PRX doesn't receive packets on any datapipe from any PTX. The only way to fix it seems to be a power cycle. In the datasheet it explains that if the MAX_RT flag is high then this could block transmission but how could this flag be thrown on a PRX? I have a "cleanup" routine that runs every 100ms on the PRX which checks the status register on the nRF to see if any of the interrupt flags are high with the IRQ pin high (interrupt was missed). If this is true, then the flags are cleared and both the TX and RX FIFO are flushed. Also in this "cleanup" routine I check the FIFO status register and if either FIFO is full then I flush them both. Even with this "cleanup" routine the PRX will still randomly lock up.

I am a bit stumped on this one. Any help would be greatly appreciated.

[Kenneth]

Difficult to say what the exact issue is here, but a few things to check:

• What is the power consumption in this "stuck" mode?
• What is the state of the VDD_PA pin? Toggle, high or low?
• Does your "cleanup" routine also use power down? If not, can you try it.

You should know that when enable dynamic payload length, the data in the PID field of the radio packet set the actual length of the payload. If you are operating in a noisy environment, or on the edge of range, the bit error rate can increase, and the 8 or 16-bit CRC might not be sufficent to filter out erroneous packets. In this case it's possible to receive payloads with erroneous payload length, due to this we have the following Note in the datasheet:

.. Always check if the packet width reported is 32 bytes or shorter when using the R_RX_PL_WID command. If its width is longer than 32 bytes then the packet contains errors and must be discarded. Discard the packet by using the Flush_RX command. ..

Also if you have a 32byte array in your application to read out payloads, and try to read out a payload longer than 32 bytes then you can experience memory overrun, which can cause any kind of issues. So it's imortant that you don't try to read out this packet, but flush it.

You can search through the datasheet for "Note:" and make sure you have handled them all.

[RAB]

Thanks for your suggestions. This would make sense because in the previous version we didn't use dynamic payload lengths. All nodes used a static payload length. I will check on the power consumption and the VDD_PA pin. I was not putting the PRX into powerdown mode in my "cleanup" routine. I was merely bring the CE low to go into standby mode. I will add this as well.

We are checking to make sure the packet width is less than 32 bytes as instructed by the datasheet. We are trying to sort through the data by capping the length to 32 bytes and reading them from the nRF24l01P anyways. After the packet has been read we always flush the RX FIFO. I will update the receive routine to just flush the packet right away if the length is reported to be over 32 bytes, rather then try and sort through it.

Thanks, R