I am writing to you after five days of intensive debugging with a hardware setup that refuses to work for LoRaWAN in the Arduino environment. I believe I have exhausted all possible software solutions and have uncovered multiple, layered issues, culminating in a corrupted build environment that even a full reinstall doesn’t fix.
My goal is simple: to create a LoRaWAN node with the XIAO nRF52840 Sense and the Wio-SX1262 for XIAO shield.
Hardware & Software
Board: Seeed Studio XIAO nRF52840 Sense (I have also tried a brand new replacement board)
LoRa Shield: Seeed Studio Wio-SX1262 for XIAO (also tried a brand new replacement)
Gateway: RAK7258 on EU868 (confirmed working with other LoRaWAN devices)
We have identified and tried to solve three distinct problems:
Phase 1: The RadioLib (SPI) Approach Initially, I assumed the shield contained a pure SX1262 chip and used the RadioLib library.
After extensive research, we confirmed the correct pinout from your official documentation (Meshtastic Kit wiki): NSS=4, DIO1=1, NRST=2, BUSY=3, RF_SW=5.
We also correctly implemented the RF switch logic using radio.setDio2AsRfSwitch(true); and radio.setRfSwitchPins(...).
Result: The code (included below) initializes the radio perfectly (radio.begin() returns success). However, the gateway never receives a JoinRequest. The node.beginOTAA() call gives a “false positive” success, and the first data send fails with a -1101 (TX_TIMEOUT).
Phase 2: The LoRa-E5 Discovery After more research, we found strong evidence that my shield is actually a LoRa-E5 module that requires UART and AT Commands, not SPI.
The fact that the exact same hardware works flawlessly with Meshtastic supports this.
Multiple forum/Reddit posts confirm that Seeed has shipped LoRa-E5 modules on boards labeled “Wio-SX1262”.
Phase 3: The Corrupted Environment Catastrophe Accepting it’s a LoRa-E5, we switched to the correct approach: using the Seeed LoRa E5 library and UART communication (Serial1).
I moved my sensor from pin D6 to D0 to free up the hardware UART pins (D6/D7).
I then tried to compile even the most basic “UART Passthrough” sketch (included below) to test the AT+ID command.
Result: The compilation fails with a fundamental linker error: undefined reference to 'Adafruit_USBD_CDC::begin(unsigned long)' and undefined reference to 'Serial'.
This error now occurs with ANY sketch I try to compile for the XIAO nRF52840, even a completely empty one with just void setup() { Serial.begin(115200); }. I have tried reinstalling the board package and completely deleting the Arduino15 folder, but the error persists.
My Questions
Is my board a LoRa-E5? Based on the evidence, this seems certain. How can you confirm this, and why is it sold under the “Wio-SX1262” name? This has caused an incredible amount of confusion.
What is causing the undefined reference to 'Serial' error? This is now the primary blocker. Why would a clean installation of the Arduino IDE and the official Seeed nRF52 board package fail to link the most basic core functions for the XIAO nRF52840? Is there a known bug or a dependency I am missing?
What is the definitive, official, tested-and-working method to get the XIAO nRF52840 + Wio-SX1262 (LoRa-E5 variant) to join a LoRaWAN network using the Arduino framework?
I am now stuck. I cannot use the SPI approach because the hardware is likely LoRa-E5. I cannot use the UART approach because my build environment is fundamentally broken for this board, and standard fixes do not work.
// This code compiles, initializes the radio successfully,
// but the gateway never receives a Join Request.
#include <RadioLib.h>
// ANONYMIZED KEYS
uint64_t devEUI = 0x0102030405060708;
uint64_t joinEUI = 0x0807060504030201;
uint8_t appKey[] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
// Pin definitions confirmed from official docs
#define PIN_LORA_NSS (4)
#define PIN_LORA_DIO1 (1)
#define PIN_LORA_NRST (2)
#define PIN_LORA_BUSY (3)
#define PIN_LORA_RFSW (5)
SX1262 radio = new Module(PIN_LORA_NSS, PIN_LORA_DIO1, PIN_LORA_NRST, PIN_LORA_BUSY);
LoRaWANNode node(&radio, &EU868);
void setup() {
Serial.begin(115200);
while(!Serial);
int state = radio.begin();
if (state != RADIOLIB_ERR_NONE) {
Serial.printf("Radio init failed: %d\n", state);
while(true);
}
radio.setDio2AsRfSwitch(true);
radio.setRfSwitchPins(PIN_LORA_RFSW, RADIOLIB_NC);
node.beginOTAA(joinEUI, devEUI, appKey, appKey);
}
void loop() {
// Fails here with -1101
node.sendReceive("A", 1);
delay(60000);
}
Code 2: The simple UART test that FAILS TO COMPILE
// This simple code fails to compile with "undefined reference to 'Serial'"
void setup() {
Serial.begin(115200);
while (!Serial);
Serial.println("Test");
Serial1.begin(9600);
}
void loop() {
if (Serial1.available()) {
Serial.write(Serial1.read());
}
if (Serial.available()) {
Serial1.write(Serial.read());
}
}
Thank you for the suggestion. A community member provided me with a set of LoRa P2P (Point-to-Point) sketches to test the basic functionality of the hardware, independent of the LoRaWAN network.
I have tested these sketches, and here are the results and my analysis.
P2P Test Setup
Hardware: Two identical setups, each with a XIAO nRF52840 + Wio-SX1262 shield.
Software:
One board was flashed with the provided SX1262_XIAOs_P2P_TX.ino sketch.
The other board was flashed with the SX1262_XIAOs_P2P_RX.ino sketch.
Key Observation from Code: I noticed that these P2P sketches do not use the special RF switch configuration lines (radio.setDio2AsRfSwitch(true); and radio.setRfSwitchPins(...)). They rely only on the basic 4-pin Module constructor.
P2P Test Result
The P2P test failed.
The TX sketch runs and reports “TX success!” in the Serial Monitor.
The RX sketch runs but never receives any packets; it continuously shows “RX timeout!”.
This was tested with the devices placed right next to each other.
Updated Analysis & Core Problem
This P2P test failure, even with the simplified code, reinforces our main problem. The fact that my identical hardware works perfectly with Meshtastic proves that the hardware itself is not faulty. Meshtastic must be performing a specific, low-level initialization sequence or radio configuration that is missing from the standard RadioLib examples (both P2P and LoRaWAN).
The P2P code fails for the same reason our LoRaWAN code fails: the radio is not being correctly configured to transmit, even though radio.begin() and radio.transmit() report success. The RF signal is likely never leaving the antenna with sufficient power.
My original questions therefore still stand, but can be refined:
What is the specific, low-level radio initialization sequence that Meshtastic uses for the XIAO nRF52840 + Wio-SX1262 combination that is missing from the standard RadioLib library examples?
Is it confirmed that my shield contains a LoRa-E5 module? If so, why does a RadioLib SPI-based sketch (like the P2P example) even pass the radio.begin() check? An SPI library should fail to initialize a UART-based module. This is very confusing.
We are also still facing a fundamental build environment issue on multiple computers where even a simple sketch fails to compile for the XIAO nRF52840 with an undefined reference to 'Serial' error. This prevents us from testing the UART/AT-command approach for the LoRa-E5.
It seems there is a deeper issue with either the RadioLib implementation for this specific hardware, or a fundamental problem with the Arduino board package for the XIAO nRF52840 that is causing both the RF issues and the compilation errors.
Any guidance on the specific radio configuration needed would be greatly appreciated.