LMIC ASSERT on line 1875: "ASSERT((LMIC.opmode & OP_TXRXPEND)!=0)"

[Bertramp]

Hi
We have a setup using an RFM95 module with a builtin level shifter and an Arduino Uno with the pin mapping below.

const lmic_pinmap lmic_pins = {
        .nss = 6,
        .rxtx = LMIC_UNUSED_PIN,
        .rst = 5,
        .dio = {2, 3, 4},
    };

Data is being transmitted and we have verified it's arrival on the receiving end just fine using the "hello world" example, but this only works once. After transmitting the data it fails the ASSERT((LMIC.opmode & OP_TXRXPEND)!=0) in LMIC.c line 1875 getting the following output in the terminal:

Starting
Packet queued
274741: EV_TXCOMPLETE (includes waiting for RX windows)
FAILURE
C:\Users\az19667\Documents\libraries\arduino-lmic-master\src\lmic.c:1875

LMIC.c lines 1874 and 1875:

static bit_t processDnData (void) {
ASSERT((LMIC.opmode & OP_TXRXPEND)!=0);

We tried to figure out where the LMIC.opmode changed or possibly failed to change correctly, but couldn't. We have also checked the pin connections, changed the wires and switched to different pins on the arduino without any luck.

Has anybody had this problem or got a hunch about what we're doing wrong?

Thanks!

[Roberto6969]

Double check connection of D0, D1 and D2 - if works only once it is problem in conection with those pins in most cases. Here is more info: #40

[Bertramp]

We fixed the issue by connecting D2 to fit the mapping.
The instructions in the Readme on using D0, D1 and D2 are a bit misleading. It says that each mode only needs 2 pins which is D0 and D1 for LoRa mode. To me means that D2 isn't needed which is why we didn't connect it at all at first.

[matthijskooijman]

@Bertramp, hm then my analysis of the code is incorrect. Your understanding of the documentation is how I had intended it, but apparently I misunderstood something.

[Bertramp]

@matthijskooijman It's plausible your analysis is wrong, but it seems to me a lot more people should've run into the issue then. It's a very essential part of using the library after all.

[jcwren]

I had this issue initially, also. I found that the issue was specifying the D2 pin (4) when it wasn't connected. The first entry is always needed (2). The second entry (3) is required for LoRa. The third entry (4) is required for FSK. If you're not using the FSK modes, then specify that as LMIC_UNUSED_PIN.

[Bertramp]

@jcwren We'll test that on occasion, it would make a lot more sense than the case that D2 is actually being used for something.

[jcwren]

Here's the problem, I believe. In hal.c, dio_states is initialized to 0's. Pins specified for DIO are configured as inputs, which turns on the internal pull-up. When they're unconnected, they will read back as a 1. In hal_io_check(), it's testing dio_state [x] against the pin for x. In this case, 'x' is 2, the pin is not connected so reads back as 1. If the two values are not equal, it inverts dio_state [x]. Next, if dio_state [x] != 0, it calls radio_irq_handler (x).

Basically, because the pin is high, it believes there's a packet to be processed and calls the FSK handler. The rest of the code isn't in the correct state for a received packet at that point, so the assert() occurs.

[matthijskooijman]

So the problem is caused by not using DIO2 but not specifying it as LMIC_UNUSED_PIN either? If so, the docs should probably be updated to make this more explicit.

[jcwren]

@matthijskooijman, yes, I believe so.

[Bertramp]

@jcwren We have also got it working using specifying DIO2 as LMIC_UNUSED_PIN, and we believe your location of the problem is correct.