fix(nrf54): keep the watchdog counting while the CPU sleeps by cvaldess · Pull Request #12049 · meshtastic/firmware

cvaldess · 2026-10-02T13:04:56Z

Summary

On nRF54, nrf52Setup() initialised the watchdog with behaviour = 0, which pauses it while the CPU sleeps and while it is halted. A core that never wakes from the tickless idle is then the one hang the watchdog cannot catch. That is how the nRF54L15-DK failed until the Arduino core's GRTC sleep timing was fixed (meshtastic/nRF54_Arduino#1): asleep for hours, nothing to reset it.

Set NRF_WDT_BEHAVIOUR_RUN_SLEEP_MASK: keep counting in sleep, stay paused in halt so a debugger stop does not reset the board.

Testing

On an nRF54L15-DK + E22-900M30S, before the core fix: with behaviour = 0 the board stayed asleep for 5 h; with this change the same hang ended in a watchdog reset about 90 s in, and the node came back on its own. Halting the core from the debugger did not reset it. Running on the DK since 2026-09-21.

🤝 Attestations

I have tested that my proposed changes behave as described.
I have tested that my proposed changes do not cause any obvious regressions on the following devices:
- Heltec (Lora32) V3
- LilyGo T-Deck
- LilyGo T-Beam
- RAK WisBlock 4631
- Seeed Studio T-1000E tracker card
- Other (please specify below)

nRF54L15-DK only; the change is in src/platform/nrf54/.

Summary by CodeRabbit

Improvements
- On nRF54 devices, the watchdog now continues counting while the CPU is asleep and pauses while the CPU is halted. This updates watchdog behavior across these processor states. The watchdog reload value and initialization flow remain unchanged.

With behaviour 0 the WDT pauses while the CPU sleeps, so a core that never wakes from the tickless idle is the one hang it cannot catch. That is how the nRF54L15-DK failed until the Arduino core's GRTC sleep timing was fixed: asleep for hours with nothing to reset it. Run in sleep, stay paused in halt so a debugger stop does not reset the board.

coderabbitai · 2026-10-02T13:05:04Z

Important

Review skipped

Review was skipped as selected files did not have any reviewable changes.

⚙️ Run configuration

Configuration used: Repository: meshtastic/firmware/.coderabbit.yaml
Review profile: CHILL
Plan: Advanced
Run ID: 84b62392-ec14-49e6-9287-25edab1ba750

📥 Commits

Reviewing files that changed from the base of the PR and between b1d59cf and 7522be4.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository: meshtastic/firmware/.coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: 9f0e8073-c66a-42fc-8e82-4a034954fccb

📥 Commits

Reviewing files that changed from the base of the PR and between 80ea7f1 and 65a7888.

📒 Files selected for processing (1)

src/platform/nrf54/main-nrf54.cpp

Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 5 remain after this review.

📝 Walkthrough

The nRF54 watchdog configuration now keeps the watchdog running during CPU sleep. The reload value and initialization flow remain unchanged.

Changes: nRF54 watchdog

Layer / File(s)	Summary
Watchdog sleep configuration `src/platform/nrf54/main-nrf54.cpp`	The watchdog behavior changes to `NRF_WDT_BEHAVIOUR_RUN_SLEEP_MASK`. The reload value remains unchanged.

Priority: ➖ Normal

Estimated code review effort: 1 (Trivial) | ~3 minutes

Change: Bug fix

Merge Risk: ⚪ Minimal · up to 65a78

The intended sleep watchdog behavior is changed, with no confirmed merge-blocking regression.

Security architecture risk: 🔵 Low · up to 65a78

The change improves recovery from a CPU that never wakes and preserves debugger behavior. However, healthy power-saving nodes can request sleep longer than the watchdog timeout. Compatibility with those intervals remains unresolved because watchdog feeding inside the platform’s delay implementation could not be verified.

Retained concerns

Low · reliability · inferred: Enabling the watchdog during sleep may reset healthy power-saving nodes before their scheduled wake. Supported sleep intervals exceed the unchanged 90-second timeout, and the visible timed-sleep path has no main-channel feed before its explicit reset. Unless the external delay implementation compensates, repeated premature resets could undermine the recovery policy and intended low-power lifecycle. Actual premature expiry is not verified.

Security review details

Security Blast Radius

inferred — The demonstrated exposure is device-local availability on nRF54 nodes using the changed watchdog configuration, particularly timed power-saving tracker and sensor modes. The available evidence does not establish an attacker-controlled trigger or cross-device compromise path.

Trust Boundaries and Controls

observed — The watchdog is a firmware-configured hardware recovery control. This PR extends its enforcement into CPU sleep without changing the visible initialization or main-channel feeding ownership.

Resilience and Maintainability Implications

inferred — The visible boot path reads the reset reason, initializes watchdog ownership, and enables and feeds the watchdog on loop entry, supporting recovery after reset. This is counterevidence to permanent source-level lockout, but it does not prove that repeated sleep and watchdog-reset cycles preserve intended operation or that external bootloader recovery is correct.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 1 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: keeping the nRF54 watchdog active during CPU sleep.
Description check	✅ Passed	The description explains the problem, implementation, testing results, affected hardware, and completed attestations. It provides sufficient detail for review and replaces the template guidance with r…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create a new PR

Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Autopilot is currently an internal CodeRabbit preview.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

github-actions · 2026-10-02T13:05:06Z

⚡ Try this PR in the Web Flasher

Note

Building this pull request… the flash button, badges and supported-board
list will appear here automatically once CI finishes.

…n-in-sleep

cvaldess marked this pull request as ready for review October 2, 2026 13:18

cvaldess added 4 commits October 5, 2026 14:27

Merge remote-tracking branch 'upstream/develop' into fix/nrf54-wdt-ru…

2b02062

…n-in-sleep

Merge remote-tracking branch 'upstream/develop' into fix/nrf54-wdt-ru…

2c152f9

…n-in-sleep

Merge remote-tracking branch 'upstream/develop' into fix/nrf54-wdt-ru…

b1d59cf

…n-in-sleep

Merge remote-tracking branch 'upstream/develop' into fix/nrf54-wdt-ru…

7522be4

…n-in-sleep

Navigation Menu

Repository navigation

fix(nrf54): keep the watchdog counting while the CPU sleeps - #12049

fix(nrf54): keep the watchdog counting while the CPU sleeps#12049
cvaldess wants to merge 5 commits into
meshtastic:developfrom
cvaldess:fix/nrf54-wdt-run-in-sleep

cvaldess commented Oct 2, 2026 •

edited by coderabbitai Bot

Loading

Uh oh!

coderabbitai Bot commented Oct 2, 2026 •

edited

Loading

Review skipped

Security review details

❌ Failed checks (1 warning)

Uh oh!

github-actions Bot commented Oct 2, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

cvaldess commented Oct 2, 2026 • edited by coderabbitai Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Testing

🤝 Attestations

Summary by CodeRabbit

Uh oh!

coderabbitai Bot commented Oct 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review skipped

Security review details

❌ Failed checks (1 warning)

Uh oh!

github-actions Bot commented Oct 2, 2026

⚡ Try this PR in the Web Flasher

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

cvaldess commented Oct 2, 2026 •

edited by coderabbitai Bot

Loading

coderabbitai Bot commented Oct 2, 2026 •

edited

Loading