RUI3 v4.2.3 STM32 — Boot loop when LoRaWAN API (set/join) called in setup() — official OTAA example also affected

Hardware: RAK3272S (WisDuo Breakout Board, Ver. C)
BSP: RAKwireless RUI STM32 v4.2.3
Arduino IDE: 2.3.8
Issue: Boot loop when any LoRaWAN API is called in setup()

Tested with:

  • Official LoRaWan_OTAA example (unmodified except band=IN865, credentials)
  • Also boot loops on the official example

Serial output:
RAK OTAA Test — IN865

[immediate reboot, repeats indefinitely]

The NWM guard never prints “Switching to LoRaWAN” — device is already
in LoRaWAN mode (AT+NWM=1 confirmed via AT commands). Reboot is
triggered by appeui/appkey/deui/band set() calls.

Welcome to the forum @oharis99

Tested the original example code with the change to IN865. It works as expected.

> at+nwm=0
OK
RAKwireless LoRaWan OTAA Example
------------------------------------------------------
Set Node device work mode Success

RAKwireless LoRaWan OTAA Example
------------------------------------------------------
Wait for LoRaWAN join...+EVT:JOIN_FAILED_RX_TIMEOUT
Wait for LoRaWAN join...+EVT:JOIN_FAILED_RX_TIMEOUT
Wait for LoRaWAN join...+EVT:JOIN_FAILED_RX_TIMEOUT
Wait for LoRaWAN join...+EVT:JOIN_FAILED_RX_TIMEOUT
Wait for LoRaWAN join...+EVT:JOIN_FAILED_RX_TIMEOUT
Wait for LoRaWAN join...+EVT:JOIN_FAILED_RX_TIMEOUT
Wait for LoRaWAN join...+EVT:JOIN_FAILED_RX_TIMEOUT
Wait for LoRaWAN join...+EVT:JOIN_FAILED_RX_TIMEOUT
Wait for LoRaWAN join...+EVT:JOIN_FAILED_RX_TIMEOUT

Forced LoRa P2P mode with at+nwm=0
Starting the app the switch to LoRaWAN mode is forcing a reset, which is expected and intended.

OK
RAKwireless LoRaWan OTAA Example
------------------------------------------------------
Set Node device work mode Success

On next startup the application is working as expected and tries to join the network (which fails here, as I do not have a IN865 setup here)

RAKwireless LoRaWan OTAA Example
------------------------------------------------------
Wait for LoRaWAN join...+EVT:JOIN_FAILED_RX_TIMEOUT
Wait for LoRaWAN join...+EVT:JOIN_FAILED_RX_TIMEOUT
Wait for LoRaWAN join...+EVT:JOIN_FAILED_RX_TIMEOUT
Wait for LoRaWAN join...+EVT:JOIN_FAILED_RX_TIMEOUT
Wait for LoRaWAN join...+EVT:JOIN_FAILED_RX_TIMEOUT
Wait for LoRaWAN join...+EVT:JOIN_FAILED_RX_TIMEOUT
Wait for LoRaWAN join...+EVT:JOIN_FAILED_RX_TIMEOUT
Wait for LoRaWAN join...+EVT:JOIN_FAILED_RX_TIMEOUT
Wait for LoRaWAN join...+EVT:JOIN_FAILED_RX_TIMEOUT

If you didn’t change anything in the code, try to send ATR to the device over USB (with trailing LN CR) to force a factory reset of the device.

Thank you @beegee for the response. For me it still reboots.

I performed a full chip erase via STM32CubeProgrammer to recover from a bad flash. After restoring firmware using the standard 3-file hex procedure (bootloader + bootloader_active + application), the device boots and runs correctly but AT+JOIN causes an immediate reboot on every attempt.

What works:

  • Device boots normally
  • All AT configuration commands work (AT+NWM, AT+BAND, AT+DEVEUI, AT+APPEUI, AT+APPKEY etc.)
  • P2P mode works — AT+PRECV=65535 puts radio into receive mode successfully
  • SERIAL_ONLY sketch works (sensors, timers)

What doesn’t work:

  • AT+JOIN=1:0:10:8 → device reboots immediately, no OK, no +EVT
  • api.lorawan.join() → same immediate reboot
  • Tested on BSP 4.2.3 and 3.4.2 — same behavior on both

Is there a complete factory firmware image for RAK3272S (STM32WLE5) that includes the LoRaWAN NVM initialization data? Or is there a procedure to restore the device to factory state without sending it back?

Hardware: RAK3272S Ver. C, STM32WLE5

When using STM32CubeProgrammer you need to flash only one file, the RAK3172-E_latest_final.hex

After flashing this firmware, run a test with just AT commands and try to join the network.

Thank you for the suggestion. After flashing the RAK3172-E_latest_final.hex file, AT configuration commands work fine but AT+JOIN still causes an immediate reboot. I suspect this may be a power brownout — I am currently powering the RAK3272S via jumper cables from a CP2102 USB-to-serial adapter. The resistance of the jumper cables may be causing a voltage drop during the radio TX current spike, triggering a brownout reset. Will test with a dedicated 3.3V supply and report back.

Sending LoRaWAN packets (whether it is a join uplink or a data uplink) can take up to 120mA current at 3.3V with a very steep rise.
You need a power supply that is able to handle this power requirement.