What should I do when getPacketLength() returns 0 in RX IRQ mode?

[frostbyte-ninja]

Hi,

I am dealing with an intermittent issue where my SX1262 radio randomly stops receiving in RX interrupt mode after a few days of uptime. According to logs, the failure starts immediately after the early-return path is taken with packetLength == 0, and the IRQ pin remains high afterwards.

std::optional<String>
LoraClient::receiveMessage()
{
  const auto packetLength{m_lora.getPacketLength()};
  if (packetLength == 0U) {
    return std::nullopt;
  }

  std::vector<byte> receiveBuffer(packetLength);
  if (const auto state{m_lora.readData(receiveBuffer.data(), receiveBuffer.size())}; state != RADIOLIB_ERR_NONE) {
    Serial.print(F("Failed to read data, code: "));
    Serial.println(state);
    return std::nullopt;
  }

  ...
}

This strongly suggests that the IRQ is left uncleared in that situation. Calling clearIrqFlags(RADIOLIB_SX126X_IRQ_ALL) should fix that, but I have not been able to confirm it yet. Also, from a software design point of view, I do not like duplicating parts of what readData() already does internally.

My questions:

• Does the fix make sense?
• Can I remove the packetLength == 0 check and always call readData() (even when the length is 0), relying on it to clear the IRQ? Is that safe and supported?
• What would readData() return in this case?

[jgromes]

getPacketLength does not clear IRQ, so I think that returning in your code after it returns really does cause stopping Rx by IRQ remaining high (as the interrupt is set for an eedge trigger). Calling readData even after getPacketLength returned 0 should be safe - in the worst case that value gets propagated to a call to readBuffer, which will proceed to read 0 bytes from the radio FIFO.

What would readData() return in this case?

That's a very good question and it depends on whether there are any additional IRQ flags set. If there are some CRC or header errors, it should return an appropriate error code. If not, then it will read 0 bytes of data into your receiveBuffer and return an OK code. Which I admit is a bit weird.

In any case it would be interesting to figure ouit why is getPacketLength returning a 0 value. Either that method itself is failing, or there are some other IRQ flags which we should be checking inside getPacketLength as well.

[frostbyte-ninja]

When this scenario occurs, it seems unlikely to be related to the expected messages (-> noise?).
I have added additional logging to gather more details, but there's currently no known way to trigger it intentionally, so it will have to be observed when it happens again.