Report program state in RTM builds

[dkovyazin]

Description

• StateProgramRunning and StateProgramExited are now set in every build, not only when NANOCLR_ENABLE_SOURCELEVELDEBUGGING is defined.
• The CLR_DBG_Commands_c_Monitor_ProgramExit broadcast stays behind that guard, since it is a debugging event rather than state.

Motivation and Context

Both bits of the debugger state mask were guarded by NANOCLR_ENABLE_SOURCELEVELDEBUGGING, so an RTM build never reported either of them. On the client side State.Initialize is 0x00000000, which makes a mask that never gains ProgramRunning (0x00000400) indistinguishable from a device that is still initializing. An RTM device therefore looks stuck before its program starts, for the entire time the program is actually running.

The visible effect is that nanoff --filedeployment against an RTM build fails with E2002 and reboots the target repeatedly, while a debug build of the same firmware on the same hardware deploys normally.

• Fixes RTM builds never report ProgramRunning or ProgramExited, so clients see the device as stuck in Initialize Home#1842

How Has This Been Tested?

• Reproduced on an ESP32-S3 target: with an RTM build, deploying files over the Wire Protocol did not go through, while a debug build of the same firmware on the same hardware deployed normally.
• Firmware carrying this change has been in use on that hardware since, with file deployment working on RTM builds.
• Compile-checked against current main for ESP32_S3_QUAD.

Types of changes

• Improvement (non-breaking change that improves a feature, code or algorithm)
• Bug fix (non-breaking change which fixes an issue with code or algorithm)
• New feature (non-breaking change which adds functionality to code)
• Breaking change (fix or feature that would cause existing functionality to change)
• Config and build (change in the configuration and build system, has no impact on code or features)
• Dev Containers (changes related with Dev Containers, has no impact on code or features)
• Dependencies/declarations (update dependencies or assembly declarations and changes associated, has no impact on code or features)
• Documentation (changes or updates in the documentation, has no impact on code or features)

Checklist

• My code follows the code style of this project (only if there are changes in source code).
• My changes require an update to the documentation (there are changes that require the docs website to be updated).
• I have updated the documentation accordingly (the changes require an update on the docs in this repo).
• I have read the CONTRIBUTING document.
• I have tested everything locally and all new and existing tests passed (only if there are changes in source code).

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: ASSERTIVE

Plan: Team

Run ID: 1eeb071b-8324-4eb6-9fb5-7570878feb22

📥 Commits

Reviewing files that changed from the base of the PR and between af5c858 and 8b89a2a.

📒 Files selected for processing (2)

• src/CLR/Core/Execution.cpp
• src/CLR/Startup/CLRStartup.cpp

💤 Files with no reviewable changes (2)

• src/CLR/Startup/CLRStartup.cpp
• src/CLR/Core/Execution.cpp

Included review availability: Your plan provides up to 2 included reviews per hour; 0 remain after this review.

---

📝 Summary

Summary by CodeRabbit

• Bug Fixes
  • Improved debugger state reporting during program startup and shutdown.
  • Ensured debugger clients receive consistent running and exited states, including builds without source-level debugging.
  • Improved compatibility for debugger clients that interpret the initial state as program initialization.

Walkthrough

The runtime now reports StateProgramRunning and StateProgramExited in builds without source-level debugging. The program-exit event remains limited to source-level debugging builds.

Changes

Debugger state reporting

Layer / File(s)	Summary
Unconditional program state updates src/CLR/Core/Execution.cpp, src/CLR/Startup/CLRStartup.cpp	The runtime sets the running and exited state bits for all builds. The program-exit event remains conditional on source-level debugging.

Estimated code review effort: 2 (Simple) | ~10 minutes

Merge Risk: ⚪ Minimal · up to 8b89a

RTM builds now report running and exited program states while retaining the debug-only exit event guard. No current merge-blocking risk remains.

Suggested reviewers: josesimoes

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the RTM program-state reporting change, is concise, and does not end with a full stop.
Description check	✅ Passed	The description directly explains the RTM state-mask bug, the conditional changes, the deployment failure, testing, and the linked issue.
Linked Issues check	✅ Passed	The changes satisfy issue [#1842] by setting StateProgramRunning and StateProgramExited unconditionally while keeping the program-exit debugging event conditional.
Out of Scope Changes check	✅ Passed	The changes are limited to the debugger state-mask updates described in [#1842]. No unrelated code changes are identified.

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[josesimoes]

The fix looks OK. Just remove the verbose comment. The reasoning is perfectly explained in the PR comments where it belongs.

[dkovyazin]

Comments removed in 8b89a2a — the reasoning stays in the PR description.

[josesimoes]

LGTM

[josesimoes]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[dkovyazin]

The two red jobs (Build_ESP32_targets ESP32_C5_THREAD and ESP32_C6_THREAD, build 65638) failed in Install IDF, not on the code: the RISC-V toolchain download returned HTTP Error 504: Gateway Time-out from the GitHub release and ran out of retries. Everything else in that run is green, including Check_Code_Style and the STM32 nightly targets. A rerun should clear it.

[nfbot]

@dkovyazin thank you again for your contribution! 🙏😄

.NET nanoFramework is all about community involvement, and no contribution is too small.
We would like to invite you to join the project's Contributors list.

Please edit it and add an entry with your GitHub username in the appropriate location (names are sorted alphabetically):

  <tr>
    <td><img src="https://github.com/dkovyazin.png?size=50" height="50" width="50" ></td>
    <td><a href="https://github.com/dkovyazin">Дмитрий</a></td>
  </tr>

(Feel free to adjust your name if it's not correct)