• State Verified Answer
  • Replies 2 replies
  • Subscribers 67 subscribers
  • Views 789 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 236467
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How to efficiently use nrf_gzll_flush_tx_fifo nrf_gzll_flush_rx_fifo

astella

To the kind attention of Nordic support team,

I'm studying documentation in https://developer.nordicsemi.com/nRF5_SDK/nRF51_SDK_v5.x.x/doc/5.2.0/html/a00140.html where it seems that every pipe has got its own private tx rx fifo:

All 8 pipes on both the Device and the Host have two First-in First-out (FIFO) buffers that can hold packets. Each pipe has a TX FIFO and an RX FIFO. The total number of packets in the FIFOs is 6, while every individual TX or RX FIFO (8 pipes x 2 = 16 in total) can store 3 packets.

Then in https://devzone.nordicsemi.com/f/nordic-q-a/3401/gazell-why-i-can-only-fill-4-pipes it does emerge that there is only one global tx/rx fifo that is shared between all pipes. May you please correct me if I am wrong? is it this way in SDK nRF5_SDK_15.2.0_9412b96? Is there a way to enlarge the fifo lenght? Is it still limited to 3 packets for rx and 3 packets for tx?

According to https://developer.nordicsemi.com/nRF5_SDK/nRF51_SDK_v5.x.x/doc/5.2.0/html/a00140.html host fifo handling, gzll protocol uses fifos to accomplish its own mechanism to avoid to receive device packets that have already been received (so that received packets have to been maintained in the rx fifo until a new different one is received) and to avoid that lost tx ack packets are not in fifo tx memory any more.

So it seems that the developer shouldn't interfere with such a mechanism to not destroy it. It seems that the most important moment when to use nrf_gzll_flush_tx_fifo is when:

'When the Host is handling packets on multiple pipes, care needs to be taken to ensure that ACK payloads in the TX FIFOs on pipes that are no longer in use, are not taking up space in the memory pool and consequently blocking communication on other pipes. To avoid such congestion, the application on the Host can flush the TX FIFOs on the pipes no longer in use.'

Theoretically, if the communication with a particular pipe had experienced some problems and the 3 packets tx fifo is full with packets that are meant for that particular pipe, and then the program switch and want to use another pipe the communication would stall (unless using nrf_gzll_flush_tx_fifo ), being the fifo queue waiting packets from the previous pipe in order to empy the fifo.  

Are there any other important moments when to use these flush routines?

Thank you for your attention

Parents
  • +1

    Hi,

     

     

    Then in https://devzone.nordicsemi.com/f/nordic-q-a/3401/gazell-why-i-can-only-fill-4-pipes it does emerge that there is only one global tx/rx fifo that is shared between all pipes. May you please correct me if I am wrong? is it this way in SDK nRF5_SDK_15.2.0_9412b96? Is there a way to enlarge the fifo lenght? Is it still limited to 3 packets for rx and 3 packets for tx?

    This is correct. It is statically allocated inside the library, and cannot be changed.

    According to https://developer.nordicsemi.com/nRF5_SDK/nRF51_SDK_v5.x.x/doc/5.2.0/html/a00140.html host fifo handling, gzll protocol uses fifos to accomplish its own mechanism to avoid to receive device packets that have already been received (so that received packets have to been maintained in the rx fifo until a new different one is received) and to avoid that lost tx ack packets are not in fifo tx memory any more.

    So it seems that the developer shouldn't interfere with such a mechanism to not destroy it. It seems that the most important moment when to use nrf_gzll_flush_tx_fifo is when:

    'When the Host is handling packets on multiple pipes, care needs to be taken to ensure that ACK payloads in the TX FIFOs on pipes that are no longer in use, are not taking up space in the memory pool and consequently blocking communication on other pipes. To avoid such congestion, the application on the Host can flush the TX FIFOs on the pipes no longer in use.'

    Theoretically, if the communication with a particular pipe had experienced some problems and the 3 packets tx fifo is full with packets that are meant for that particular pipe, and then the program switch and want to use another pipe the communication would stall (unless using nrf_gzll_flush_tx_fifo ), being the fifo queue waiting packets from the previous pipe in order to empy the fifo.  

    Are there any other important moments when to use these flush routines?

     Before uploading payloads, you should check if you have any room left in the FIFO. If the return states that there's no space left, you can choose to flush the fifo, or handle this by waiting for the other transfers to complete. In the case that you're sending ACK payloads, it is not easy to handle this specific scenario unless the transmitter (gazell device) sends another "dummy payload" to fetch the ACK. If you do not send a dummy payload to the host, you can get into a scenario where you have preloaded ACK payloads to a specific pipe (or pipes) that aren't communicated on. This would then effectively block other pipes.

     

    Kind regards,

    Håkon

Reply
  • +1

    Hi,

     

     

    Then in https://devzone.nordicsemi.com/f/nordic-q-a/3401/gazell-why-i-can-only-fill-4-pipes it does emerge that there is only one global tx/rx fifo that is shared between all pipes. May you please correct me if I am wrong? is it this way in SDK nRF5_SDK_15.2.0_9412b96? Is there a way to enlarge the fifo lenght? Is it still limited to 3 packets for rx and 3 packets for tx?

    This is correct. It is statically allocated inside the library, and cannot be changed.

    According to https://developer.nordicsemi.com/nRF5_SDK/nRF51_SDK_v5.x.x/doc/5.2.0/html/a00140.html host fifo handling, gzll protocol uses fifos to accomplish its own mechanism to avoid to receive device packets that have already been received (so that received packets have to been maintained in the rx fifo until a new different one is received) and to avoid that lost tx ack packets are not in fifo tx memory any more.

    So it seems that the developer shouldn't interfere with such a mechanism to not destroy it. It seems that the most important moment when to use nrf_gzll_flush_tx_fifo is when:

    'When the Host is handling packets on multiple pipes, care needs to be taken to ensure that ACK payloads in the TX FIFOs on pipes that are no longer in use, are not taking up space in the memory pool and consequently blocking communication on other pipes. To avoid such congestion, the application on the Host can flush the TX FIFOs on the pipes no longer in use.'

    Theoretically, if the communication with a particular pipe had experienced some problems and the 3 packets tx fifo is full with packets that are meant for that particular pipe, and then the program switch and want to use another pipe the communication would stall (unless using nrf_gzll_flush_tx_fifo ), being the fifo queue waiting packets from the previous pipe in order to empy the fifo.  

    Are there any other important moments when to use these flush routines?

     Before uploading payloads, you should check if you have any room left in the FIFO. If the return states that there's no space left, you can choose to flush the fifo, or handle this by waiting for the other transfers to complete. In the case that you're sending ACK payloads, it is not easy to handle this specific scenario unless the transmitter (gazell device) sends another "dummy payload" to fetch the ACK. If you do not send a dummy payload to the host, you can get into a scenario where you have preloaded ACK payloads to a specific pipe (or pipes) that aren't communicated on. This would then effectively block other pipes.

     

    Kind regards,

    Håkon

Children
Related