Issue with RX Window Configuration for SX1262 on LoRaWAN Network

[nikorainto]

Hello,

I am currently testing the RadioLib and LoRaWAN example on a custom board featuring an STM32L072RB MCU and a Waveshare SX1262 module. The testing environment includes a nationwide set of LoRaWAN gateways utilizing the ThingPark network platform for device management and message logging. ThingPark supports LoRaWAN v1.1.

I observed that my join request appeared in the gateway's log and a response was sent. However, it seems the RX window closes before my device can receive the join acceptance. Additionally, the JoinAccept packet log shows: "Delivery Failed Cause on RX1: Class A: LRC selected RX2(C0)." On my device I can see state being -1116 (RADIOLIB_LORAWAN_NO_DOWNLINK)

Previously, I have been using CubeCell with LoRaWAN v1.0.2 on the same network. When the signal is weak, it can take between 10-15 seconds for the JoinAccept to appear on the device. I'm considering whether this might be the case here as well. I believe that by default, RadioLib waits 5-6 seconds for a response. Should I consider increasing RADIOLIB_LORAWAN_JOIN_ACCEPT_DELAY_1_MS? Does that sound correct?

You can view my current code here: GitHub Link

[StevenCellist]

Hi @nikorainto, the problem appears to be with ThingPark, judging by the upper screenshot as it already reports an error. The main observation is that ThingPark apparently tried to schedule at Rx1 but failed to do so with that error you copied (Class A: LRC selected RX2(C0)).
I have never used ThingPark so I can't comment on what this means - I would recommend you do a Google search or whatever your preferred search engine would be.
But OK, then ThingPark tried to use Rx2 at SF12 - this would be expected to work. Can you turn on RADIOLIB_DEBUG_PROTOCOL flag in your compile options and re-run your test? You would only need to do it once (or maybe twice in case it was a fluke); no need to spam the airwaves with SF12 continuously. It if not work, it not work.

[nikorainto]

I now face a different issue that is not related to TTN or ThingPark. Instead, it's related to my coding skills and my current difficulty in debugging the code effectively. This is the current code I'm testing with to have both BME280 sensor and Radiolib working on same project

#include <Wire.h>
#include <Adafruit_Sensor.h>
#include <Adafruit_BME280.h>
#include "config.h"

Adafruit_BME280 bme;

void setup()
{
  Wire.begin();
  bme.begin(0x76);

  radio.begin();
  radio.setRfSwitchPins(PA3, PA2);

  node.beginOTAA(joinEUI, devEUI, nwkKey, appKey);
  node.activateOTAA();
}

void loop()
{
}

For some reason I'm not able to understand when both Wire.begin(); and node.activateOTAA(); are enabled then code will go to infinite loop without obvious reason. If either is commented then code works normally. Does anyone with more knowledge than me understand what is happening even without having debug logs?

[jgromes]

Nothing obvious comes to mind, though since you have an SWD, you should be able to just run the code with a debugger and then stop execution once it gets into that infinite loop ... then you can just examine the stack trace to tell where that loops is, and how the program got there.

[nikorainto]

I tried to debug this more but seems like dead end. Code does not stop to any breakpoint in any line but instead starts from this

Reset_Handler:  
   ldr   r0, =_estack
   mov   sp, r0          /* set stack pointer */

and when clicking pause it stops to this line

Infinite_Loop:
  b  Infinite_Loop

with following call stack

WWDG_IRQHandler@0x0800c52c (c:\Users\me\.platformio\packages\framework-arduinoststm32\system\Drivers\CMSIS\Device\ST\STM32L0xx\Source\Templates\gcc\startup_stm32l072xx.s:110)
<signal handler called>@0xfffffff9 (Unknown Source:0)
__libc_init_array@0x08010cc0 (\__libc_init_array.dbgasm:1)
Reset_Handler@0x0800c50e (c:\Users\me\.platformio\packages\framework-arduinoststm32\system\Drivers\CMSIS\Device\ST\STM32L0xx\Source\Templates\gcc\startup_stm32l072xx.s:89)

and that keeps repeating if I try continue and pause again 🤔Also nothing special can be seen in terminal debug console. If I run code with just Radiolib parts or only BME280 parts then everything works

[jgromes]

This would deserve a more in-depth exploration with the debugger, but for what it's worth ...

1. On STM32, WWDG is the windowed watchdog, and if I remember correctly, the default implementation of its IRQ handler is an infinite loop. So if the watchdog is being enabled and then timing out (e.g. if some fucntion takes too long without feeding the watchdog), it will trigger the IRQ, hence the infinite loop.
2. However, I also seem to recall that the WWDG_IRQHandler is the point in the interrupt vector that interrupts will jump to if the don't have an IRQ handler. So if there's an interrupt that's missing its handler, it would jump into WWDG_IRQHandler without actually being triggered by the WWDG.

Take the above with a grain of salt, it's been a while since I've seen this behavior of STM32 program ending up in WWDG_IRQHandler

[nikorainto]

Reason for this was found. I had wrong openocd_target defined on my board definition. Had to be stm32l0_dual_bank instead of stm32l0

  "debug": {
    "jlink_device": "STM32L072RB",
    "openocd_target": "stm32l0_dual_bank",
    "svd_path": "STM32L07x.svd"
  },

[K4KDR]

Don't have a specific answer for you, but as I've been learning how to use the various LoRaWAN capabilities in RadioLib, a LOT of useful information has been revealed by un-commenting one or more of the 'debug' lines in /src/BuildOptUser.h

... besides revealing all kinds of LoRaWAN info to point you in the right direction, the debug info that appears in your serial terminal can of course also be a huge help with a module like the BME280, too!

[nikorainto]

There is just an issue that I have only SWD port available on my board and no serial port so I think that option will not work for me 😅

[K4KDR]

I only have a couple of STM32 devices but all of them allow me to connect via a terminal app (using CuteCom on linux) to the device that usually presents itself as something like /dev/ttyACM0. But I'm very much a novice with these modules so perhaps that is not true for all of those boards

[nikorainto]

Yes, I also have some Arduino and STM32 development boards without the LoRa module that work well with serial port debugging. However, I am new to this field also and recently built a custom board with only an SWD port. I thought it would provide the same debugging capabilities, but it seems that I can only rely on breakpoints in the code for debugging 😬

[nikorainto]

I have a separate project for reading BME280 sensor values and it works well. Also I have another with Radiolib and LoRaWAN and that works. Now I'm trying to combine these two but ran into this problem

[HeadBoffin]

I am new to this field also and recently built a custom board with only an SWD port.

You aren't alone in making this error but the only solution is to either bodge two wires on to the side of the chip or re-do your board. Once you have done the development work you can return to your no-serial PCB for deployment. However I'd point ou that the minimum I have on production boards are either pads or 1.27mm header - the SWD connector provides a Gnd, so the minimum is ONE pin for Tx.

Does anyone with more knowledge than me understand what is happening even without having debug logs?

Advanced guessing would be to look at an overlap of pin use. Or as Jan says, use the debugger even if it takes an evening of learning the debugger rather than hoping you can operate it by brute force. Or, as I do, use a bigger / better board for development & debugging and then port it over.