Watchdog timer — api.system.wdt.disable() missing, blocks WDT + long sleep coexistence (RAK3272S / RUI3 BSP 4.2.4)

  • BSP version: 4.2.4, target: RAK3272S (STM32WLE5)
  • Issue: api.system.wdt has no disable() method — only enable() and reset()
  • 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.

1 Like

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 with wdt.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:

  1. Are the IWDG timeout findings above correct? Is the ≤7s chunk window documented?
  2. Is sleep.all() expected to reset LoRaWAN session state? Is there a way to preserve the session across sleep?
  3. 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) from loop() breaks LoRaWAN session state — use indefinite sleep.all() with timer-driven wake instead
  • sleep.all() does not feed IWDG — requires explicit wdt.reset() from a periodic timer
  • wdt.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.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.