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?

[harryAI]

The picture is as follow. The text on the chip line by line is

"NRF  O"

"24L01+"

"1621LR"

PS: The picture is already took by iPhone, but I know the picture is a little blur. If you do really need to see a clear text from the picture, I can use a better camera (if I have) to take another picture.

[ovrebekk]

Hi 

Can you do a readout of all the configuration registers in the nRF24L01+ and send it to me?

Then I can try to replicate your setup, and see if I spot the same issue on my end. 

You might also want to purchase some modules from a known genuine source, and see if the problem is the same. 
In China we work with a distributor called Xuntong, and they are making some modules based on the nRF24L01+ that we know to be genuine:
http://freqchina.com/plus/view.php?aid=1091

Best regards
Torbjørn

 

[harryAI]

> Can you do a readout of all the configuration registers in the nRF24L01+ and send it to me?

Could you give me your email? I can send to you via email.

[harryAI]

Here you are. The statuses are printed after RF initialization when power-on. The RF has not transmitted any data.

By the way, the reproduce rate of this issue is very low. I just saw twice or three times for a very long time. If you cannot reproduce this issue, I don't know how to distinguish (A) RF module has bug, but just has not happen or (B) the genuine RF module does not have this bug. Anyway, still prove the RF register values to you.

Nordic nRF24L01+ Register values
Reg 0x00: 0E
Reg 0x01: 00
Reg 0x02: 01
Reg 0x03: 03
Reg 0x04: 10
Reg 0x05: 4F
Reg 0x06: 27
Reg 0x07: 0E
Reg 0x08: 00
Reg 0x09: 00
Reg 0x0A: 52
Reg 0x0B: C2
Reg 0x0C: C3
Reg 0x0D: C4
Reg 0x0E: C5
Reg 0x0F: C6
Reg 0x10: 52
Reg 0x11: 00
Reg 0x12: 00
Reg 0x13: 00
Reg 0x14: 00
Reg 0x15: 00
Reg 0x16: 00
Reg 0x17: 11
Reg 0x1C: 3F
Reg 0x1D: 06

[ovrebekk]

Hi 

How many packets did you send in that time, when you got 2 or 3 packets with MAX_RT?

I have put up a small test and will leave it over the weekend, to see if I can record any MAX_RT interrupts. So far I have sent over 15000 packets and I have only seen TX_DS interrupts. 

I do have one question, why the 0x1C and 0x1D registers are set?
These features don't work when ACK's are disabled, and are usually set to 0 in this case. 

Best regards
Torbjørn

[harryAI]

> How many packets did you send in that time, when you got 2 or 3 packets with MAX_RT?

When MAX_RT happens, RF is sending packet every 250ms, i.e., 4 packets every 1 second  for reporting a periodically information. The period is lasting for about 1 ~ 2 hours.

> I do have one question, why the 0x1C and 0x1D registers are set?

I just adopt the sample codes of dynamic payload, and Nordic sample codes change 0x1C and 0x1D registers in `radio_pl.c`. Copy the codes as follows:

/*****************************************************************************
* Changed from esb/radio_esb.c *
* Enables: *
* - ACK payload *
* - Dynamic payload width *
* - Dynamic ACK *
*****************************************************************************/
hal_nrf_enable_ack_pl(); // Try to enable ack payload

// When the features are locked, the FEATURE and DYNPD are read out 0x00
// even after we have tried to enable ack payload. This mean that we need to
// activate the features.
if(hal_nrf_read_reg(FEATURE) == 0x00 && (hal_nrf_read_reg(DYNPD) == 0x00))
{
hal_nrf_lock_unlock (); // Activate features
hal_nrf_enable_ack_pl(); // Enables payload in ack
}

hal_nrf_enable_dynamic_pl(); // Enables dynamic payload
hal_nrf_setup_dyn_pl(ALL_PIPES); // Sets up dynamic payload on

[ovrebekk]

Hi

This might explain the problem. Using features like ACK payload, dynamic payload length or dynamic ACK are not compatible with clearing the EN_AA register (ie disabling ACK's). 

Either you have to enable ACK's through the EN_AA register and use these features, or you have to disable these features completely. 

If you want to disable ACK's while using the dynamic payload length feature you should enable ACK in the EN_AA register and enable the dynamic ACK feature, so that you can send packet without ACK even if EN_AA is enabled. 

I did some testing on my own, and after a million packets I don't see a single MAX_RT interrupt occur, but in my testing I didn't enable ack payload and dynamic payload length. 

Best regards
Torbjørn

[harryAI]

> If you want to disable ACK's while using the dynamic payload length feature you should enable ACK in the EN_AA register and enable the dynamic ACK feature, so that you can send packet without ACK even if EN_AA is enabled

Based on your comments, so my codes need to change as follows, right? (Please help to confirm).

  hal_nrf_open_pipe(HAL_NRF_PIPE0, true);  // Then open pipe0, w/autoack  -> Harry: enable EN_AA Ack

  // hal_nrf_enable_ack_pl(); // Try to enable ack payload -> Harry: comment out two lines of these codes

However, I have one question. Since I don't want ACK, why can I disable EN_AA as well, i.e., 

  hal_nrf_open_pipe(HAL_NRF_PIPE0, false);

[ovrebekk]

Hi 

Do you need dynamic payload length or not?

If you don't need dynamic payload length you can just run hal_nrf_open_pipe(HAL_NRF_PIPE0, false), and make sure not to run hal_nrf_enable_ack_pl(), hal_nrf_enable_ack_pl(), hal_nrf_enable_dynamic_pl() or hal_nrf_setup_dyn_pl(ALL_PIPES). 

If you need dynamic payload length the only way to achieve this is to run hal_nrf_open_pipe(HAL_NRF_PIPE0, true), hal_nrf_setup_dyn_pl(ALL_PIPES) and hal_nrf_enable_dynamic_pl().

The reason for this is that enabling the pipe with EN_AA = 0 removes the 9 bit PCF field in the payload which is used to support the dynamic payload length, ACK payload and dynamic ACK features. 

In the documentation this might be referred to as either Shockburst mode (EN_AA = 0), or Enhanced Shockburst mode (EN_AA = 1). 

Best regards
Torbjørn

[harryAI]

Yes, I need dynamic payload length.

Therefore, my codes will call

* run hal_nrf_open_pipe(HAL_NRF_PIPE0, true), 

* hal_nrf_setup_dyn_pl(ALL_PIPES)

* hal_nrf_enable_dynamic_pl().

and will NOT call (comment out)

* hal_nrf_enable_ack_pl();

Got it. thank you very much.