SX1262 rx no irq response after header valid irq

[won.huh]

Hi,

There is an issue that rx done or rx timeout irq never fires after header valid irq came when the node try to RX so mac state check timer keeps expiring.
This happens sometimes when it is running rx sensitivity test with repeating echo request / response usually with relatively low signal.

Here is the irq handler code I am using like below. I guess it could be fixed with a software timer for rx but I don’t understand why lora chip is stuck after header valid irq fires. Also, I need to make sure if it can happen with sx1262 (any history or known issue?) or if the code could has a potential problem related to the issue.

void SX126X_LoRaRadio::handle_dio1_irq()
{
uint16_t irq_status = get_irq_status();
clear_irq_status(IRQ_RADIO_ALL);
if ((irq_status & IRQ_TX_DONE) == IRQ_TX_DONE) {
if (_radio_events->tx_done) {
_radio_events->tx_done();
}
}

if ((irq_status & IRQ_RX_DONE) == IRQ_RX_DONE) {
    if ((irq_status & IRQ_CRC_ERROR) == IRQ_CRC_ERROR) {
        if (_radio_events && _radio_events->rx_error) {
            _radio_events->rx_error();
        }
    } else {
        if (_radio_events->rx_done) {
            uint8_t offset = 0;
            uint8_t payload_len = 0;
            int16_t rssi = 0;
            int8_t snr = 0;
            packet_status_t pkt_status;

            // from https://github.com/Lora-net/LoRaMac-node/releases/tag/v4.5.1
            // WORKAROUND - Implicit Header Mode Timeout Behavior, see DS_SX1261-2_V1.2 datasheet chapter 15.3
            // RegRtcControl = @address 0x0902
            write_to_register(0x0902, 0x00);
            // RegEventMask = @address 0x0944
            write_to_register(0x0944, read_register(0x0944) | (1 << 1));
            // WORKAROUND END

            get_rx_buffer_status(&payload_len, &offset);
            read_fifo(_data_buffer, payload_len, offset);
            get_packet_status(&pkt_status);
            if (pkt_status.modem_type == MODEM_FSK) {
                rssi = pkt_status.params.gfsk.rssi_sync;
            } else {
                rssi = pkt_status.params.lora.rssi_pkt;
                snr = pkt_status.params.lora.snr_pkt;
            }

            _radio_events->rx_done(_data_buffer, payload_len, rssi, snr);
        }
    }
}

if((irq_status & IRQ_HEADER_VALID) == IRQ_HEADER_VALID)
{
    if(_radio_events->rx_valid)
    {
        _radio_events->rx_valid();
    }
}

if ((irq_status & IRQ_CAD_DONE) == IRQ_CAD_DONE) {
    if (_radio_events->cad_done) {
        _radio_events->cad_done((irq_status & IRQ_CAD_ACTIVITY_DETECTED)
                == IRQ_CAD_ACTIVITY_DETECTED);
    }
}

if ((irq_status & IRQ_RX_TX_TIMEOUT) == IRQ_RX_TX_TIMEOUT) {
    if ((_radio_events->tx_timeout) && (_operation_mode == MODE_TX)) {
        _radio_events->tx_timeout();
    } else if ((_radio_events && _radio_events->rx_timeout) && (_operation_mode == MODE_RX)) {
        _radio_events->rx_timeout();
    }
}

}

[mantoine]

Hello @won.huh,

Thanks for your post!

Can I get more information like the configuration of your chip (LoRa / GFSK, modulation and packet parameters)?

@won.huh

Also, I need to make sure if it can happen with sx1262 (any history or known issue?) or if the code could has a potential problem related to the issue.

There is nothing that comes to my mind regarding a potential issue.

[won.huh]

Problem solved.
clearing all irq bits can cause this issue but it happens only some devices and weak signal state.
Fix that with change clear bits currently set.

@won.huh

clear_irq_status(IRQ_RADIO_ALL);

[gregg_haensgen]

Hi won.huh.

I believe I am seeing exactly what you reported above and have been having a heck of a time finding a workaround for it. I am using CAD but I don’t know if it’s a factor in this issue we see. Basically once we receive a RX ERROR (typically and weaker signals) we run into an issue like you reported. It would seem that the radio is still operating correctly after the issue happens. I can see CAD running and I can see that CAD is properly working in terms of going into constant RX for our timeout that we have set (5 seconds). We even added a debug message now which is (!Rx). This indicates that CAD detected preamble or data and we went into constant RX but didn’t get a packet. You can see how we start missing all subsequent packets after RX ERROR. We tried a few different things once we detect the RX Error but didn’t have much luck. What is interesting is that if I force a poll (tx and rx) from my device when I enter this mode we always recover. Could you provide some additional details on your workaround? Interested in understanding what bits you had to clear? I think you are saying clearing all the bits causes this issue and interested in understanding if you determined what bit was causing the issue. Appreciate it very much.

[t1g1]

Hi,
SX126x and LLCC68 interrupts are more level type than edge type. Once SX126x sets DIO interrupt pin HIGH, it won’t go low until clear_irq_status doesn’t clear all set IRQ flag. You can use clear_irq_status(IRQ_RADIO_ALL), but then you will miss all IRQs that happened between get_irq_status() and clear_irq_status(IRQ_RADIO_ALL).
It is better to use loop:
uint16_t irq_status = 0; uint16_t tmp; do { tmp= get_irq_status(); if (tmp) { clear_irq_status(tmp); irq_status |= tmp; } } while (tmp); // or while(digitalRead(DIO_IRQ_PIN);