This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

MAX_RT interrupt still happens even if retransmit is off

Dear Nordic,

I met a problem while using nRF24L01+ about MAX_RT interrupt.

In my codes, I disabled RF HW retransmit (hal_nrf_set_auto_retr(0, RF_RETRANS_DELAY);) because I use our software codes to handle retransmit. Therefore, RF should not report "HAL_NRF_MAX_RT" interrupt. However, I still receive "HAL_NRF_MAX_RT" in very rare situations. I saw twice so far for a very long time.

My question is since RF module auto retransmition is off, why does nRF24L01+ still report "HAL_NRF_MAX_RT" interrupt?? Is this nRF24L01+ bug? Or how could I do to get rid of these
MAX_RT interrupt?

Parents
  • Hi Harry

    The MAX_RT interrupt occurs if no ACK is received, even when no retransmits are enabled. 

    In other words this will happen if you don't get an ACK on your TX packet. 

    Best regards
    Torbjørn

  • Thank your update.

    One more information: in our codes, we have disabled ACK by 

    hal_nrf_open_pipe(HAL_NRF_PIPE0, false);       // Open pipe0, without/autoack

    This means the receiver will never ACK the sender's TX.

    Two more questions:

    1. Based on your reply, MAX_RT occurs if no ACK. Since we have disabled ACK, I guess we should see MAX_RT interrupt very frequently, but why do we just rarely see the MAX_RT interrupt? (I saw twice so far for a very long time)

    2. We have used software to handle re-transmit. If we don't want MAX_RT interrupt, how could we do?

  • Hi 

    The function looks like this:

    void hal_nrf_write_tx_payload_noack(const uint8_t *tx_pload, uint8_t length)
    {
      hal_nrf_write_multibyte_reg(W_TX_PAYLOAD_NOACK, tx_pload, length);
    }

    It is identical to the normal TX function, except the command byte is 0xB0 (W_TX_PAYLOAD_NOACK) instead of 0xA0 (W_TX_PAYLOAD).

    harryAI said:
    Another question: I saw you call `hal_nrf_set_rx_payload_width(HAL_NRF_PIPE0, 8);`. My question is since we already enable dynamic payload `hal_nrf_enable_dynamic_payload(true);`, why do we still need to call set payload width?

     You are correct. There is no need to set the payload length when using dynamic payload length, and this line can safely be removed from the code. 

    harryAI said:
    By the way, the data rate in my test is 250K bps (yours is HAL_NRF_2MBPS). I think this will not affect anything, but still mention this difference.

     Thanks for the information. I agree this should not make a difference in this case. 

    Best regards
    Torbjørn

  • In my library, I did not find `W_TX_PAYLOAD_NOACK`, but I find `WR_NAC_TX_PLOAD` below. I think the definition of `W_TX_PAYLOAD_NOACK` is the same as`WR_NAC_TX_PLOAD`, right? Please double confirm in case any unexpected issue happens.

    #define WR_NAC_TX_PLOAD 0xB0

  • Hi

    As long as the value is 0xB0 the name is irrelevant, so you can use that define, yes Slight smile

    Best regards
    Torbjørn

  • I tried to follow all of your codes. However, the same problem, the system still cannot receive any TX_DS after sending packets. After tracing the root cause, I found hal_nrf_write_multibyte_reg() does not have any codes to handle 0xB0 command (WR_NAC_TX_PLOAD). I copy hal_nrf_write_multibyte_reg() below.

    I think the key problem now is my RF library (nAN24-12 version 2.1 subversion 2624) is much different from yours, so I cannot use your code directly. May I know what RF library do you use? If possible, could you also provide the link as well? we will evaluate if we will upgrade our library to your version or not if the effort is not big. If the change is big, I think we will give up this problem, because this issue MAX_RT event is just a trivial issue. In addition, you have provided a solution mentioned above to treat MAX_RT as the TX_DS case, and we have changed it in our codes. 

    ---

    void hal_nrf_write_multibyte_reg(uint8_t reg, uint8_t *pbuf, uint8_t length)
    {
    switch(reg)
    {
    case HAL_NRF_PIPE0:
    case HAL_NRF_PIPE1:
    case HAL_NRF_TX:
    length = hal_nrf_get_address_width();
    CSN_LOW();
    hal_nrf_rw(WRITE_REG + RX_ADDR_P0 + reg);
    break;

    case HAL_NRF_TX_PLOAD:
    CSN_LOW();
    hal_nrf_rw(WR_TX_PLOAD);
    break;
    default:
    break;
    }

    while(length--)
    {
    hal_nrf_rw(*pbuf++);
    }

    CSN_HIGH();
    }

  • Hi

    Sorry for the late reply, I was on vacation for the last two weeks. 

    You should be able to extend the hal_nrf_write_multibyte_reg function to support the WR_NAC_TX_PLOAD, by adding another case in the switch for WR_NAC_TX_PLOAD. 

    If you want to have a look at my code I made it available here:
    https://github.com/ovrebekk/nrf52-l01-hal-example

    It is based on nAN24-12, but I have made some small changes to it, including a more generic way of handling the write_multibyte function. 

    Best regards
    Torbjørn

Reply Children
Related