probe-rs: Debugging when wfe is used doesn't appear to work

I am unable to observe my code stopping at breakpoints when wfe() is used.

Steps to reproduce the behavior:

Clone the https://github.com/titanclass/microrust-start repo
Open the project in VS Code
Install the probe-rs debugger and VS Code extension
Set a breakpoint on the loop statement of the main.rs
Debug from within VS Code

I expect the debugger to stop at the breakpoint set. If I comment out the wfe() call then all is well i.e. I observe the debugger stopping at the breakpoint.

For further context, please note that if I debug via pyocd with the following configuration then all appears well:

{
    /* 
     * Requires the Rust Language Server (RLS) and Cortex-Debug extensions
     * https://marketplace.visualstudio.com/items?itemName=rust-lang.rust
     * https://marketplace.visualstudio.com/items?itemName=marus25.cortex-debug
     */
    "version": "0.2.0",
    "configurations": [
        {
            "type": "cortex-debug",
            "request": "launch",
            "name": "Debug (pyocd)",
            "servertype": "pyocd",
            "cwd": "${workspaceRoot}",
            "preLaunchTask": "Cargo Build (debug)",
            "runToMain": true,
            "executable": "./target/thumbv7em-none-eabihf/debug/microrust-start",
            "device": "nRF52833_xxAA",
            "boardId": "9904360259994e45001a401100000064000000009796990b",
            "targetId": "nrf52"
        }
    ]
}

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 18 (13 by maintainers)

Commits related to this issue

Merge #724 724: If SLEEP'ing target, assert C_HALT for certain debug commands r=Yatekii a=noppej This is a (as yet untested by the user) fix to resolve #703 `probe-rs-debugger` will now assert t... — committed to probe-rs/probe-rs by bors[bot] 3 years ago

Most upvoted comments

Update: I have identified the root cause. The debugger fails to correctly set the hardware breakpoint while the target is in sleeping. The cortex-m architecture requires the debugger to update the DHCSR register’s C_HALT value to ‘1’ before it attempts certain core operations during sleep mode. I will make the appropriate updates and after my testing, will send you a branch to test against, but it likely won’t be until Jul 13th.

noppej on Jun 30, 2021

Re-opening, as the current fix for #724 only solves the problem when using VSCode’s attach mode. The fix for launch mode will be done in a separate PR for the probe-rs/vscode repo.

noppej on Jul 29, 2021

Update: After another remote session with @huntc I can now reproduce this on my own hardware, so that will help a lot with resolution. The ‘trick’ was that the problem only happens when VSCode is using a ‘launch’ configuration, but does not happen when using an ‘attach’ configuration against a running debug instance of the probe-rs-debugger. That surprised me, but I will build in additional run-time logging to try to narrow down the root cause.

noppej on Jun 28, 2021

Update: After a remote session with @huntc, I confirmed the following:

The breakpoint is being set correctly.
The chip halts on the breakpoint.
The debugger does not correctly detect the change in status from ‘running’ to ‘halted’.

Workaround: In VSCode, click on the ‘Pause’ (F6) button. The debugger will show that the code is halted on the breakpoint.

Note: Further investigation is needed, but it appears the synchronization of run/halt status between the debugger and the chip is related to a sequence of events where the breakpoint is being set while the chip is in a wfe() instruction.

noppej on Jun 23, 2021

Some hint maybe: I think other toolkits automatically set debug flags on the core which enable debugging on wfe/wfi. This would be part of the upcoming sequences as it is different for each chip. I believe having a look in the pyOCD source for the nRF51 might help 😃

Yatekii on Jun 21, 2021

Have you tried this? https://github.com/probe-rs/probe-rs/issues/350#issuecomment-740550519 UPD: Oops, sorry, apparently you have a completely different chip.

Disasm on Jun 20, 2021