Skip to main content
Visitor II
August 7, 2026
Question

STM32WL (LoRaWAN MW 2.5.0 / MAC 1.0.4 / AU915) freezes uplinks after LinkADRReq on ChirpStack — stable on TTN

  • August 7, 2026
  • 0 replies
  • 25 views

Hello everyone,

I'm developing a LoRaWAN end-device based on the STM32WL using the official ST LoRaWAN stack, and I'm facing a reproducible freeze that only happens with ChirpStack, not with TTN.

Environment

  • MCU / Board: STM32WL55JC
  • Stack: STM32Cube_FW_WL — APPLICATION V1.3.0, MW_LORAWAN V2.5.0, L2_SPEC V1.0.4, RP_SPEC RP002-1.0.1
  • Region: AU915 (sub-band 1, channels 0–7 + 64)
  • Activation: OTAA, Class A, unconfirmed uplinks every 30 s
  • Same hardware and same gateway used in both tests

Problem On ChirpStack, after the join the device sends only 4–5 uplinks and then freezes permanently: it stops transmitting and never recovers. Current measurement shows the radio stuck at ~14 mA (looks like it stays in RX), while a normal TX peak is ~74 mA.

Key observation The freeze always happens right after ChirpStack sends LinkADRReq commands. In my logs, ADR ramps the TX power (PWR 0 → 2 → 5 → 7) on consecutive uplinks, and the device locks up on a frame where both RX1 and RX2 time out. The device answers LinkADRAns correctly (dr_ack / tx_power_ack / ch_mask_ack all true) before locking.

What I already ruled out

  • Not DevNonce: cleaned on the server, join works fine.
  • Not the sensors: sensor read executes in ~1 ms (confirmed by log).
  • Not brownout: the exact same hardware (including the multimeter in series) ran 4 hours stable on TTN, sending every 30 s without a single loss.
  • Not LmHandlerIsBusy skip: I added a log in the busy branch and it does not trigger at the freeze.

Decisive test When I disable ADR at runtime with LmHandlerSetAdrEnable(false) (device advertises adr: false, so ChirpStack stops sending LinkADRReq), the device runs 46+ consecutive uplinks with no freeze. Re-enabling ADR brings the freeze back.

Questions

  1. Has anyone seen the ST LoRaWAN MW (2.5.0) stack freeze the radio in RX after processing LinkADRReq in US915/AU915?
  2. Is this a known issue fixed in a newer MW/LoRaMac-node version? If so, which version?
  3. Is there a ChirpStack-side ADR configuration that avoids triggering this (e.g., ADR pacing, disabling per-uplink LinkADRReq)?