IRQ not triggered even though the emission status seems ok.

[Thomass]

Hi, 

I've been using the nRF24l01+ for some time now and am quite satisfied. I'm having a new issue that I'm unable to explain and for which I would greatly appreciate some help. 

I have two units comunicating together using the following scheme:

1: T = t0 - Module 1 sends message 1

2: T = t0 - Module 2 receives message 1

3: T = t0 + 30 ms - Module 2 sends msg 2 

4: T = t0 + 30 ms - Module 1 receives msg 2 

5: T = t0 + 40 ms - Module 1 sends msg 3

6: T = t0 + 50 ms - Module 1 sends msg 4

7: T = t0 + 100 ms - The process starts again. 

My problem is that when I send msg2 using the module 2, the tx status goes to 1, which means that the emission went well, but there is no IRQ triggered on the module 1 side. Is there a configuration where the emitting unit sees everything as normal whereas the receiving unit doesn't call an interruption ? 

The problem gets even more strange, because when I remove step 5 or step 6, so I just send one message after receiveing msg 2, then everything starts to work normally again... 

Any clue to what the problem might be ? 

Thank you all for any help you may provide, 

Regards, 

[run_ar]

Hi,

Are you using Auto acknowledgement (TX_DS is asserted when the packet is transmitted, if Auto_ack is activated this bit is set high only when ACK is received)? Auto Retransmisssion (ARD)? What is the ARD delay? and what is the baudrate and packet size?

[Thomass]

Hi, 

Thank you for your answer. 
I'm using a specefic library to communicate with my device. This library states that the Auto ACK is enabled by default so I suppose I'm using the Auto ACK. 
I have disables the ARD so I'm sending the message once. 

The buadrate is 250 Kbps and the packet size is 32 bytes. I'm using the dynamic payload option. 

To add some extra details, it really looks like the devices are communicating because the TX_DS is only asserted when Module 1 is powered. But it looks like Module 1 isn't receiving the information from the device. 

I hope it clarifies a bit my previous message.

Thanks in advance for your help, 

Regards

[run_ar]

How have you disabled ARD? do you mean you set ARD to zero, or that you configured ARC to 0. As far as I can see from the specification ARD needs to be long enough for your device to receive the ack packet from the peer. minimum 500 µs for 250kbits. Set ARC to 0 to disable re-transmits.

[Thomass]

Sorry, I meant that I disabled the ARC by setting it to zero. 
The ARD was by default to 250µs and I just tried to increase it to a higher value with no succes.  

[Thomass]

I'm working on cleaning my code so that I can post a version of it. 

[run_ar]

Could you also make sure you are checking the status register and that you are actually getting a TX_DS interrupt and not the MAX_RT interrupt?

[Thomass]

Sorry for the delay, I was quite busy with another project. 
I can confirm that it is indeed a TX_DS interrupt that I get. 

I'm continuing the investigation on my side as well and so far I've been able to extract only the "RF24" part of my code and send dummy messages. Like that it seems to work normally so it might be related to something else in my code. But still it doesn't seem to depend on the payload I send because changing the payload doesn't change the behaviour... 

Is there anything in the nRF24 that might explain a correclty sent ACK but not a interruption ? 

I'll keep you updated if I find something new. 

Regards,