MAX_RT interrupt still happens even if retransmit is off

[harryAI]

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?

[ovrebekk]

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

[harryAI]

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?

[ovrebekk]

Hi

That looks fine, I guess it's a slightly different implementation of the hal_nrf libraries. 

Did you add the dynamic ACK configuration?

If yes, did it change the behavior?

If it still doesn't work, can you send me the code you use to upload packets, and a printout of your config register after you have configured the device?

Best regards
Torbjørn

[harryAI]

Hi Torbjorn,

I check my code. I use `hal_nrf_write_tx_pload()` to send payload.

I want to try your codes, but I found my nRF libraries does not have `hal_nrf_write_tx_payload_noack(..)` this function. Could you paste this function to me?

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?

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.

[ovrebekk]

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

[harryAI]

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

[ovrebekk]

Hi

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

Best regards
Torbjørn

[harryAI]

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();
}

[ovrebekk]

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

[harryAI]

OK. Thank your information. I will look at that.

[ovrebekk]

No problem, the best of luck