[mgse]

For me, 'restart' is generally the most used operation during debug. The vast majority of the time I want to rerun through the init code to clear out the registers and any previous transactions. If I've set something up incorrectly, I can always set a breakpoint and adjust.

So I'm not seeing an immediate benefit to direct modification for my normal workflow. There may be good use cases when writing code that isn't HW dependent or if the compile/flash cycle takes a long time, but those aren't problems I've had very often over the last ~10 years.

[gvb]

Ditto.

In addition, usually when I do something wrong in an embedded system the only way to recover is a hard reset and reload. Mishandled interrupt, corrupted stack, jump to a random location, etc.

In embedded systems, there are an infinite number of ways to crash such that there is only one way to recover (reset and reload). There are very few ways to crash that leave a non-reset recovery.

[xyzzy123]

Interesting, I guess it depends on "how embedded" you are. For linux-based routers/gateways (edge of embedded really) the compile-flash-boot cycle can be rather long, but the standard workarounds (scp-after-build or NFS mount a work dir) work adequately.

That said, anything which reduces cycle times is good.