defmt::println!("Hello, world!") does not produce output in the terminal window.

Code to repro.

hardware:

• nucleo-F767ZI powered over usb, nothing attached to pins.

software:

• probe-rs-debugger-0.3.3.vsix, probe-rs-debugger 0.12.0, probe-run 0.3.1

Finally getting around to trying out debugging with probe-rs! It was pretty easy to setup, however I'm running into a few issues.

probe-rs is correctly stopping on breakpoints (see bottom left) but the UI is not updating, nor is it filling the variables table.

When attempting to debug, vscode probe-rs-debug doesnt halt on reset and I believe it actually picks up state from the previous session (cant confirm though). Upon trying to manually attempt a reset, the session drops out. In other words, cant seem to start a fresh debugging session.

board: nrf52840-mdk (maker diary)

These are the contents of my launch.json.

{
    "version": "0.2.0",
    "configurations": [
        {
            "preLaunchTask": "${defaultBuildTask}",
            "type": "probe-rs-debug",
            "request": "launch",
            "name": "rustBoot launch",
            "program_binary": "${workspaceFolder}/boards/target/thumbv7em-none-eabihf/release/nrf52840",
            "chip": "nRF52840_xxAA",
            "connect_under_reset": false,
            "speed": 24000,
            "runtimeExecutable": "probe-rs-debugger",
            "runtimeArgs": [
                "debug",
                "--dap"
            ],
            "core_index": 0,
            "flashing_enabled": true,
            "reset_after_flashing": true,
            "halt_after_reset": true,
            "console_log_level": "Info",
            // "svdFile": "${workspaceRoot}/nrf52840.svd"
        },
        {
            "type": "probe-rs-debug",
            "request": "attach",
            "name": "rustBoot attach",
            "server": "127.0.0.1:50001",
            "cwd": "${workspaceFolder}",
            "program_binary": "${workspaceFolder}/boards/target/thumbv7em-none-eabihf/release/nrf52840",
            "chip": "nRF52840_xxAA",
            "connect_under_reset": false,
            "speed": 24000,
            "core_index": 0,
            "flashing_enabled": false,
            "reset_after_flashing": false,
            "halt_after_reset": true,
            "console_log_level": "Info"
        }
    ]
}

There are a couple of other accompanying issues which I believe may be related to this. (have screenshots for these problems, if you need them).

• Errors in extracting the location of local variables
• Error when unwrapping any kind of option. (cant find file)
• Cant seem to get defmt logs out. (defmt macros and rtt is enabled)

I'm not entirely sure if this is due to it being an alpha build or if something's wrong with my set-up.

I installed the probe-rs vscode extension. Probe-rs detects my chip and my port ,but isn't able to debug my Rust program.

Here is my debug console output:

Received DAP Request sequence #1 : initialize
   Sent DAP Response sequence #1 : initialize

Received DAP Request sequence #2 : launch
   Sent DAP Response sequence #2 : launch
ERROR: [2021-12-23T01:46:48Z WARN  probe_rs::config::registry] Found chip nRF52833_xxAA which matches given partial name nRF52833. Consider specifying its full name.

probe-rs-debugger CONSOLE: ....Closing session from  :127.0.0.1:33256
probe-rs-debugger CONSOLE: DAP Protocol server exiting

Triggered DAP Event: probe-rs-show-message

Here is my launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "probe-rs-debug",
            "request": "launch",
            "name": "led_roulette_debugger",
            "cwd": "${workspaceFolder}",
            "programBinary": "/home/raunaksingh/RustProjects/discovery/microbit/target/thumbv7em-none-eabihf/debug/led-roulette.d", //!MODIFY
            "chip": "nRF52833", //!MODIFY
            "connectUnderReset": true,
            "runtimeExecutable": "probe-rs-debugger",
            "runtimeArgs": [
                "debug",
                "--dap"
            ],
            "coreIndex": 0,
            "flashingEnabled": true,
            "resetAfterFlashing": true,
            "haltAfterReset": true,
            "consoleLogLevel": "Info", //Error, Warn, Info, Debug, Trace 
        }
    ]
}

I am trying to flash my code to the nRF52833 on the Microbit. I am on Ubuntu Linux.

Automatic code formatting with prettier gives us consistent code style without the need for any stylistic discussions.

When using the recommended VSCode extension, code is automatically formatted on save.

Adherence to the prettier code style is checked in CI.

First part of #20.

Code to repro.
Discussion on rs-probe:matrix.org..

hardware:

• nucleo-F767ZI powered over usb, nothing attached to pins.

software:

• probe-rs-debugger-0.3.3.vsix, probe-rs-debugger 0.12.0, probe-run 0.3.1
• "hello world" and stm32f7xx-hal with features = ["stm32f767", "rt"].

add'l info:

• 'probe-run --chip stm32f767zi target/thumbv7em-none-eabihf/debug/hello' works.
• 'probe-rs-debugger from command line works'

partial workaround: with enable "reset after flash" but disable "halt after reset", hitting F5 builds, flashes, hits the bp in main reliably, and can hit multiple explicit bps

Initially the target was flashed and debuggee was launched, but never hit the initial bp set in main. This coincided with a notification popup with "Unable to open 'asm.S': Unable to read file '/home/jonas/dev/cortex-m-rt/asm.S' (Error: Unable to resolve nonexistent file '/home/jonas/dev/cortex-m-rt/asm.S')."

Debug output showed the following:

Received DAP Request sequence #7 : stackTrace
ERROR: [2022-01-15T20:16:32Z WARN  probe_rs::probe::stlink] send_jtag_command 242 failed: SwdApFault
ERROR: [2022-01-15T20:16:32Z INFO  probe_rs::debug] Failed to retrieve debug information for program counter 0xfffffffe: Do not have unwind info for the given address.
   Sent DAP Response sequence #7 : stackTrace

Received DAP Request sequence #8 : stackTrace
ERROR: [2022-01-15T20:16:32Z WARN  probe_rs::probe::stlink] send_jtag_command 242 failed: SwdApFault
ERROR: [2022-01-15T20:16:32Z INFO  probe_rs::debug] Failed to retrieve debug information for program counter 0xfffffffe: Do not have unwind info for the given address.
   Sent DAP Response sequence #8 : stackTrace

When I clicked the debug control restart button, then it hit the initial bp in main, but after that was not able to step reliably.

@adamgreig response on matrix: darryln: hmm, a few weird things going on - the error about asm.S indicates it's trying to work out what's happening when the program counter is inside the init code that runs before main, which comes from that file, suggesting your breakpoint has triggered too early/right at reset but later, the PC is at FFFFFFFE, which isn't a valid PC and suggests a fault has been taken, and then the chip fails to respond after that too? specifically FFFFFFFE means the processor faulted while processing a fault and therefore entered lockup.

Reverts probe-rs/vscode#32

@dbrgn ... bringing forward my requests from #32:

• Please can we ensure we do not reformat src/debugProtocol.json ... this file is downloaded from the DAP spec in one of the npm scripts.
• I really appreciate the work you've done here, but I'd prefer if we can hold of a few days with merging this, until #31 has been merged (just to avoid unnecessary conflict resolution on the latter).

This PR was motivated by discussions in #7, and will require rework of the equivalent functionality in probe-rs-debugger. It will involve a big code change in both repo's.

In the first iterations of this extension, the launch and attach terminology was interpreted to apply to the debug adapter process. In other words, "launch a new instance of the debug adapter", or "attach to a to an existing debug adapter process". - Both operations allowed flashing and resetting of the target process running on the probe.

• Neither operations allowed the debug adapter session to last for more than one session of the target process on the probe.

The proposed change will reinterpret the launch and attach terminology to apply to the target process running on the probe. To help clarify the different behaviours, I will use the following terminology:

• debug session: This refers to host side process, and ...
  • Starts when a user initiates either a launch or attach request, and ...
  • Ends when the user either initiates disconnect request, or chooses to Stop a host side debug session.
• target session: This refers to the target side process, and ...
  • Starts when the target device boots and executes the firmware program, and ...
  • Ends when the target device processing halts as a result of a unrecoverable exception, or as part of a Reset request, or when the device looses power.

launch request type

1. Start a debug session : i. Connect to the target device and executes a Reset request so that a new target session is started ii. Optionally flashes the target device firmware with the binary to be executed

attach request type

2. Start a debug session : i. Connect to the target device, but do NOT issue `Reset, so that the existing target session is uninterrupted

Common behaviour to both launch and attach request types

3. Support all standard debug behaviours, such as "Pause", "Breakpoints", RTT, etc.
4. The Reset request will cause probe-rs, to restart the target device, and associated target session. i. This will honour the value of the halt_after_reset flag. ii. The debug session is not affected.
5. The Disconnect request in the debug session will ... i. Instruct probe-rs to disconnect from the target device. ii. This implicitly ends the debug session. iii. The state of the target session is not affected. iv. There are some subtleties depending on launch vs attach as described in the MS DAP Specification for the Disconnect Request
6. The Stop function (Terminate request) in the debug session will behave the same as the disconnect, except ... i. The debug session will send a stop request to halt the target session before disconnecting. ii. There are some subtleties depending on launch vs attach as described in the MS DAP Specification for the Terminate Request

Running probe-rs-debugger as a standalone for a VSCode debug session

In most cases, the VSCode debug extension will take care of automatically launching (and ending) the probe-rs-debugger executable to act as the debug adapter for probe-rs.

It is possible for the user to take control of this, by running probe-rs-debugger from the command line, with the following command

• probe-rs-debugger debug --dap --port <any availably TCP/IP port number>

Any VSCode debug session can then attach to the specified on the server where probe-rs-debugger runs, and use the functionality above.

7. Such a server debug session implies the following: i. In order for VSCode to know where to find the debug adapter, the user needs to add the appropriate TCP host IP address and port number to the launch.json configuration, by adding the option "server":"<host address>:<port number>" (e.g. "server":"127.0.0.1:50000") ii. Such a server debug session will put the management (start and stop) of the probe-rs-debugger process completely under control of the user.

Further reading:

The above proposal aims to be consistent with the process described in the VSCode debug docs

This fix for #15 includes the following:

• In addition to checking for error code, also check for the possibility of a process signal.
• Previously the probe-rs-debugger process was started with child_process.execFile, which has a default maxBuffer for stdio of 1024 * 1024. When the stdout or stderr (RUST_LOG output is handled this way) exceeded this, VSCode would terminate the process and truncate the output ... and because we didn't test the signal, we never saw the SIGTERM event happening, and it looked as if the probe-rs-debugger failed silently. I have changed this to use child_process.spawn, which uses Stream objects instead of Buffer objects to handle the stdio from the child process.
• Bump the version number of the extension to 0.3.3

After working through #14 Im trying several target and debugger combinations to try to get a working debug session ust to see what it is supposed to look like. Currently attempting an STM32F407 discovery board with stilnk. But similarly to a jlink the session starts and communicates with the debugger but after a second or two, the session abruptly stops with no feedback. I found the trace debug which is obvious in retrospect (though not listed on the website and probably should be)

• Linux
• vscode 1.61.2
• probe-rs-debugger upstream master 4ba46f40f436e8cec452ce4a5ae570b21d26d156
• vscode upstream master 78242eb09be01398fb3cefe94278d4986fd0543b

Trace log https://gist.github.com/jacobrosenthal/a714ba3bc63b7e956f6a94d09701ed80

probe-rs recently adopted the tracing crate for logging. This opened up the possibility to cleanup how logging was implemented in the VSCode extension and associated probe-rs-debugger.

This PR will do the following:

• As a maintenance task, update the extension dependencies, and bump the version number.
• Add a launch.json setting to direct probe-rs logging to a JSON file, which can later be analyzed with the log viewer.
• Remove any probe-rs (RUST_LOG) logging from the data being reported in the VSCode debug console. It is currently interspersed with debug adapter logging, and although somewhat informative, it makes it less than useful when analyzing probe-rs specific issues.
• Refactor the VSCode extension and probe-rs-debugger handling of MS DAP events and messages, to be more useful (objective opinion) to users of the extension.
• probe-rs-debugger logging will happen according to these rules:
  1. If the RUST_LOG environment variable is set, use it as a LevelFilter to configure a subscriber that logs to a file in the system's application data directory.
  2. Irrespective of theRUST_LOG environment variable, configure a subscriber that will write with LevelFilter::ERROR to stderr (because these errors are picked up and reported to the user by the VSCode extension).

NOTE This release requires changes to the launch.json files in user projects

• The consoleLog property only supports one of three values [Console, Info, Debug]
• The extension will now honour env properties, for example:

  "env": {
      "RUST_LOG": "warn",
      "DEFMT_LOG": "debug"
  }
  

For testing, feel free to use the extension binary

Would you object to a PR that introduces prettier and eslint to the codebase? Right now it's a bit of a mess due to no consistent code style (probably because it's based on a plugin template) 🙂