piggyback fails with 6 transmitters

[Landry]

Hi,

I'm close to finishing the implementation of a system with a recording device with nrf51822, working with 6 sensors with nrf24L01.

The recorder is in receiving mode, sensors are in transmitter mode, each talking to a different pipe of the receiver. To stop sensors at the end of the recording, the receiver send piggybackly a STOP command, so that next time the sensor send a packet, it receives the stop command from the recorder.

When I have 4 sensors, everything work well. But for 5 and 6 sensors, the stop process fails : some sensors are stopped, some continue to record. The failing sensors never are the same.

To eventually stop, I have to reboot my nrf51822 and go to the stop process again (which this time work because there are now less than 6 transmitters)

So I dug into the problem, trying to collect clues.

It appears that the nrf51822 continues to retrieve the recording packets, but when I try to write in the tx fifo with nrf_esb_add_packet_to_tx_fifo function, it happens to return 0 for the unstoppable pipes.

The strange thing is that I only try to write it if the tx fifo for this pipe is empty (through nrf_esb_get_tx_fifo_packet_count function), and if the total number of pending packets in all tx fifo (and rx_fifo) are less than 10 (by making a sum recursively for each pipe with nrf_esb_get_tx_fifo_packet_count and nrf_esb_get_rx_fifo_packet_count).

As well, payload length is fixed and defined at 32 bytes, pointer is no way null, and pipe is between 0 to 5. So the requirements of the function seem checked...

Version of nRF51 SDK lib is 5.2.0, using keil RTX.

Do you have any idea of what I might be doing wrong ? Is it a known issue ? Are there some additionnal registers or device states I might check ?

Thank you for your help and concern.

Regards

Edit (02/20/2015) : After performing a few more tests, it seems that the major issue is the function nrf_esb_add_packet_to_tx_fifo at some point always returning 0 for a specific pipe, until I reset the whole chip. What can be done if it occurs, (flush ? reset something ?) assuming that as I mentionned previously I check each parameters that can cause it before I call the function ?

As a reminder, there are two main problems in my system, that may be somehow connected. Please consider having a look at the other topic here : devzone.nordicsemi.com/.../

[Asbjørn]

Would it be possible to share your code with us? I would encourage you to open a new support case in our MyPage system on our website in order to keep your code private.

The nrf_esb_add_packet_to_tx_fifo returns a zero/false if:

If pipe was invalid, payload pointer was NULL, payload length was invalid, insufficient space in FIFO memory pool or insufficient packets in TX queue.

Could it be that one of the parameters are not fulfilled. For example is the pipe closed? What if you try to re-open the pipe in question? What's the fifo status on the pipe when you see the occur?

[Landry]

Thank you for your help. I work with custom hardware, and it's a big project, so the code "as is" may not be very useful. I'm writing a simple project running on PCA10000 board to go further in tests, but for now I can give you the following sample code illustrating failure, that checks the content you asked for.

if(!ESB_isEmetteur())
{
	if(!nrf_esb_add_packet_to_tx_fifo(currentPipe, buf, 32, NRF_ESB_PACKET_USE_ACK);//NRF_ESB_PACKET_NO_ACK))
{
	afterPipeState = nrf_esb_get_enabled_prx_pipes();//contains 0x3F
	afterThisTXFifoNbOfPackets = nrf_esb_get_tx_fifo_packet_count(currentPipe);//contains 0
	afterAllTXFifoNbOfPackets = nbPacketsInAllTxFifos();	//contains 4, recursive nrf_esb_get_tx_fifo_packet_count for all pipes 
	afterNRFEnabled = nrf_esb_is_enabled(); //contains 1
}
}

Is there any other quick tests I might perform ? Thank you,