my TX FIFO remains full

[Hmissa]

Hi, I have adapted the RF24 with my STM32, but I had a problem when sending it, it always sends the first data and ignores the other data. I had as a conclusion that the TX FIFO always remains full. When I added the flush_tx function at the end of the write function, my application runs very well.

Any comment?

[TMRh20]

Does the happen if you run any of the examples? Can you modify an example or post a small code snippet that demonstrates this behaviour?

On Nov 12, 2020, at 8:44 AM, Hmissa notifications@github.com wrote:

 Hi, I have adapted the RF24 with my STM32, but I had a problem when sending it, it always sends the first data and ignores the other data. I had as a conclusion that the TX FIFO always remains full. When I added the flush_tx function at the end of the write function, my application runs very well.

Any comment?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[2bndy5]

What does write() return?

• If it always returns false, then the payload will always remain in the TX FIFO. Thus, every consecutive call to write() will keep retrying to send the artifact payload in the top level while writing a new payload to any next available level of the TX FIFO.
  EDIT: This assessment doesn't hold true because of this if block

The write() function:

1. writes a new payload to the TX FIFO
   • @Hmissa flush_tx() should be called before this step so that you can still call reUseTX() after a failed transmission. Remember that the reUseTX() function is only concerned with the top level of the TX FIFO.
2. holds CE pin HiGH until transmission fails or succeeds, then returns the CE pin LOW
3. clears the MAX_RT flag (which indicates that the latest transmission failed) upon function end.
   • This step is needed for continued operation of the TX FIFO in the event of a transmission failure.

Please tell me you didn't use setAutoAck(false) on only the receiving node(s) because that is a sure way to get the behavior you described. If this is not the case, then your transmitter is not getting the ACK packets it's waiting for, which is usually a power stability problem for the receiving node (or it can also be caused by too many receivers listening to the same address at the same time).

@TMRh20 If the intention of write() is to only manage 1 payload from the TX FIFO, then @Hmissa suggestion is well warranted. In fact, this is what my circuitpython library does for its blocking send() function.

[Hmissa]

@TMRh20 The example is Getting started I did'nt have access to my hardware this week, next week I modify an example I think this issue will produce other problems in the Network layer

[Hmissa]

@2bndy5 : Concerning the problem of power supply stability I put a capacity of 100uF between VCC and GND. For the other remarks I will check them next week. Thanks

[2bndy5]

@Hmissa I forgot about this if block that clears the TX FIFO on failed transmissions. So, my initial assessment does not hold up (unless your application is using a mix of write() and other write*() calls). It would help to see your code (if possible) and know how your module behaves when running the getting started example.

[Hmissa]

@2bndy5 I use flush_tx() just before the return 1 of the write function after checking the transmission success and I don't have a failed transmission.

Regarding your remark about setAutoAck (false), I put it in both nodes and it worked fine (without flush_tx). (Thanks)

[2bndy5]

Does that mean this is resolved? Can we close this issue?

[Hmissa]

Yes it is resolved