1.4 SerialGateway freezes

[Goppo]

Hi there,

today I've updated my two dimmable LED Actuators (enhanced to RGB) and the gateway to version 1.4.

Everything worked fine until I tried to control an (accidentally) unpowered device.
After I realized that I tried to control the wrong device, I tried to light up the second one. Nothing happened.
After a reset of the serial gateway, everything worked again.

Is that an known issue, or something that someone can reproduce?
I'm not sure, but I think with version 1.3 I never ran in that issue.

Best regards
Goppo

[hek]

Haven't heard of this. Can you reproduce it again?

[epierre]

@hek I'm not sure I can reproduce it since I read the serial port, but it happened twice yesterday for me... and the same program on a different machine (but in 1.3) never has this issue)

[Goppo]

@hek yep, always with the result.

[Goppo]

Damn.
Yestersday I could freeze the gateway all the the time.
2 minutes ago, it' worked.

I will observe it and clarify the conditions

[Yveaux]

@hek Could it be that the transmit buffer is not flushed when a transmission fails after automatic-ack retrying?
Didn't look in the code yet...

[hek]

@Yveaux

Would be great if you have some kind of idea . How/where did you mean I should flush?

@Goppo
Do you have the amplified radio version on you gateway? I'm suspecting a powering issue. In the cases where the sensor is shut down your gateway-radio will send a burst 15 messages. This could very well cause some issues if you get a voltage drop.

[Goppo]

@hek
Yes I do,
Thanks for the tip. I will try if lowering the PA level.

[Yveaux]

@hek said:

Would be great if you have some kind of idea . How/where did you mean I should flush?

On a failed transmit the message stays in the tx buffer iirr, have to look it up in the data sheet. If this is the case you have to explicitly clear the tx buffer. I'll come back to this; no time right now...

[Yveaux]

@hek Looked it up in the datasheet:

If the TX FIFO (PRX) contains more than one payload to a PTX, payloads are handled using the first in –
first out principle. The TX FIFO (PRX) is blocked if all pending payloads are addressed to a PTX where the
link is lost. In this case, the MCU can flush the TX FIFO (PRX) by using the FLUSH_TX command.
.....
While executing the Auto Retransmit feature, the number of retransmits can reach the maximum number
defined in ARC. If this happens, the nRF24L01+ asserts the MAX_RT IRQ and returns to standby-I mode.
.....
MAX_RT IRQ is asserted if the auto retransmit counter (ARC_CNT) exceeds the programmed maximum limit
(ARC). In Figure 24. the packet transmission ends with a MAX_RT IRQ. The payload in TX FIFO is NOT
removed and the MCU decides the next step in the protocol. A toggle of the CE starts a new transmitting
sequence of the same packet. The payload can be removed from the TX FIFO using the FLUSH_TX command.

The FIFO is 3 entries big, so 3 successive failed transmissions to the same destination will block the transmission.
This FIFO needs to be flushed after a failed transmission (indicated by the MAX_RT IRQ) by executing the FLUSH_TX command.
Add the following method to the NRF24 class:

uint8_t RF24::flush_tx(void)
{
  return spiTrans( FLUSH_TX );
}

and when you're at it, please also add (used e.g. by the sniffer):

uint8_t RF24::flush_rx(void)
{
  return spiTrans( FLUSH_RX );
}

This might very well be a very nasted bug bugging the 1.4 users...

[hek]

@Yveaux

Ohh.. interesting.

So are you saying we should flush_tx after every failed send? Or only after 3 consecutive send-fails to the same address?

[Yveaux]

@hek after every failed send.

[hek]

@Yveaux

Can you make some tests perhaps? And create a pull req with the changes in RF24 and MySensor.cpp if you see any improvements?

[Yveaux]

@hek will take some time but I'll see what I can do. I'll get back with some data.

[hek]

@Yveaux

Take your time. We don't have any deadlines or bosses hanging over the shoulder here

[Yveaux]

@hek true, but I have a gut feeling some troubles reported on this forum lately could be related to this. Furthermore I've seen strange repeated messages on air, but didn't investigate yet...

[hek]

@Yveaux

One shouldn't underestimate a gut feeling. They are often proven to be right.

[Yveaux]

@hek Ok, gut feeling was wrong this time
Buried deep inside the nRF24 driver (RF24::write) is standard flush when transmission fails:

//Max retries exceeded
if( status & _BV(MAX_RT)){
  flush_tx(); //Only going to be 1 packet int the FIFO at a time using this method, so just flush
  return 0;
}

[hek]

@Yveaux

Ohh.. nice digging anyway.