- BSP version: 4.2.4, target: RAK3272S (STM32WLE5)
- Issue:
api.system.wdthas nodisable()method — onlyenable()andreset() - Why it matters:
sleep.all()does not feed IWDG (confirmed by test — device reboots after 8s of sleep). Without disable, WDT cannot be scoped to blocking operations only. - Request: Add
api.system.wdt.disable()— or confirm a supported pattern for WDT + long sleep
The watchdog of the STM32WLE5 cannot be disabled.You have to take care of retriggering the WDT from your code.
Reply:
Thanks — understood, we implemented chunked sleep with manual wdt.reset() between each chunk to retrigger the IWDG from application code.
During testing we confirmed the following — please let us know if these findings are correct and documented anywhere:
wdt.enable(8000)is capped at 8000ms by RUI3 regardless of value passed- Actual IWDG timeout at 8000ms: ~7877ms (LSI slightly fast)
- Using ≤7s
sleep.all()chunks withwdt.reset()between each — IWDG does not fire, chunked approach works
However after implementing chunked sleep we hit a new issue: api.system.sleep.all() — even a single call after a successful join — causes the RUI3 stack to autonomously de-join and initiate a new OTAA exchange. The application joined flag stays true, so api.lorawan.send() is called but returns false because the stack is internally rejoining. Pattern every time:
+EVT:JOINED
TX OK ← fires before any sleep
TX FAIL ← after first sleep.all(), stack has internally de-joined
TX FAIL ← all subsequent TXes fail until rejoin completes
Confirmed this is sleep.all() specifically — replacing it with delay() gives stable TX indefinitely.
Follow-up questions:
- Are the IWDG timeout findings above correct? Is the ≤7s chunk window documented?
- Is
sleep.all()expected to reset LoRaWAN session state? Is there a way to preserve the session across sleep? - Is there a RUI3-supported low-power sleep API that keeps the LoRaWAN stack intact and is safe to use with manual IWDG retriggering?
Current workaround is delay() with periodic wdt.reset() — functional on bench but not viable for battery-powered field deployment.
Additional note: We checked the locally installed RUI3 examples (RUI_V3_examples ) — there are no sample sketches showing api.system.wdt used alongside LoRaWAN. A minimal official example combining WDT retriggering with sleep.all() and OTAA would be very helpful for users hitting this scenario.
Reply:
Resolved — posting the fix in case it helps others.
The root cause was calling sleep.all(duration) from inside loop(). Even a single call with a short duration causes the RUI3 stack to autonomously de-join and initiate a new OTAA exchange, making all subsequent api.lorawan.send() calls fail. The application joined flag stays true so the failure is silent until you see the nonces replaying in the air after +EVT:JOINED.
The fix was switching to the timer-driven pattern used in the official RAK examples (RUI3-Power-Test, RUI3-Sensor-Node):
// Three timers:
// TIMER_TX — periodic, fires sendPayload()
// TIMER_WDT — periodic every 5s, fires wdt.reset() to feed IWDG during sleep
// TIMER_JOIN — one-shot, fires join retry after backoff delay
void loop() {
api.system.sleep.all(); // indefinite — no duration
}
TX is now stable across all cycles. IWDG is fed by TIMER_WDT every 5s during sleep — no chunked sleep needed.
Summary of confirmed findings on RAK3272S / RUI3:
sleep.all(duration)fromloop()breaks LoRaWAN session state — use indefinitesleep.all()with timer-driven wake insteadsleep.all()does not feed IWDG — requires explicitwdt.reset()from a periodic timerwdt.enable()is capped at 8000ms by RUI3; actual timeout ~7877ms (LSI slightly fast)- IWDG cannot be disabled on STM32WLE5 — persists across soft resets
Would still be useful to have this documented officially — no WDT + LoRaWAN example exists in the bundled RUI_V3_examples.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.