search

probe-rs / vscode

VSCode debug extension for probe-rs. It uses the MS DAP protocol to communicate directly with the probe (via probe-rs), and supports basic command line debugging in addition to VSCode UI.
https://probe.rs/
Other
66 stars 6 forks source link

Couple of probably related issues - unable to reset nrf52840-mdk #8

Closed nihalpasham closed 3 years ago

nihalpasham commented 3 years ago

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).

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

noppej commented 3 years ago

Hi Nihal,

I will try my best to get you going, but need a bit more info first ...

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.

Are you referring to expecting a halt on reset when you manually reset? That is not something we have tested and I would not expect it to work. There is an Issue logged to improve this, but we have not actioned it yet. If you are referring to expecting a halt on reset after the flashing, then we need to dig into that, as it may be a problem with either the code or the config. Please clarify :)

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)

Can you please send me the .cargo/config file as well as the Cargo.toml file you are using?

  • Cant seem to get defmt logs out. (defmt macros and rtt is enabled)

The current posted release does not support RTT. There is a WIP Pull Request where it mostly works, but I suggest you wait a week or so until we have it fully tested and merged before you try that.

nihalpasham commented 3 years ago

Are you referring to expecting a halt on reset when you manually reset? That is not something we have tested and I would not expect it to work. There is an Issue logged to improve this, but we have not actioned it yet. If you are referring to expecting a halt on reset after the flashing, then we need to dig into that, as it may be a problem with either the code or the config. Please clarify :)

  • halt on reset after flashing: works but not always i.e. in some instances, it goes into an undefined state. (on more than one occasion I noticed it landed in some exception that must have been triggered by part of the code I'm trying to debug or possibly some previous state.)
  • manual halt on reset: - yep, can confirm this does not work.

Can you please send me the .cargo/config file as well as the Cargo.toml file you are using?

config.toml: 

[target.'cfg(all(target_arch = "arm", target_os = "none"))']
runner = "probe-run --chip nRF52840_xxAA"
rustflags = [
  "-C", "linker=flip-link",
  "-C", "link-arg=-Tlink.x",
  "-C", "link-arg=-Tdefmt.x",
  # This is needed if your flash or ram addresses are not aligned to 0x10000 in memory.x
  # See https://github.com/rust-embedded/cortex-m-quickstart/pull/95
  "-C", "link-arg=--nmagic",
]

[build]
target = "thumbv7em-none-eabihf"

Cargo.toml: workspace

[workspace]

members = ["rustBoot-update",
           "rustBoot-hal", 
           "test_firmware/*/*", 
           "test_impls/*"
           ]

[profile.dev]
incremental = false
codegen-units = 1
debug = true
lto = false

[profile.release]
debug = true
lto = true
opt-level = "s"
panic = "abort"

Cargo.toml: project

[package]
build = "build.rs"
edition = "2018"
name = "nrf52840"
version = "0.1.0"

# makes `cargo check --all-targets` work
[[bin]]
bench = false
doctest = false
name = "nrf52840"
test = false

[dependencies]
cortex-m-rt = "0.6.15"
defmt = "0.2.3"
defmt-rtt = {version = "0.2.0"}
panic-probe = {version = "0.2.0", features = ["print-defmt"]}
rustBoot-hal = {path = "../../rustBoot-hal", default-features = false, features = ["nrf52840"]}
rustBoot-update = {path = "../../rustBoot-update"}

[features]
default = ['defmt-default']
# these features are required by defmt
defmt-debug = []
defmt-default = []
defmt-error = []
defmt-info = []
defmt-trace = []
defmt-warn = []

# [workspace]

The current posted release does not support RTT. There is a WIP Pull Request where it mostly works, but I suggest you wait a week or so until we have it fully tested and merged before you try that.

Noted. cool.

noppej commented 3 years ago
  • manual halt on reset: - yep, can confirm this does not work.

If you are using VSCode's 'launch' mode, you can press the green anti-clockwise arrow "restart" button that shows up during a debug session. This will reset the probe, and start a new debug session.

I will add some documentation about this in the next update.

noppej commented 3 years ago
  • halt on reset after flashing: works but not always i.e. in some instances, it goes into an undefined state. (on more than one occasion I noticed it landed in some exception that must have been triggered by part of the code I'm trying to debug or possibly some previous state.)

This hardly surprise me. Thanks for the additional description. The default 'launch' behavior for VSCode is to use STDIO as a transport for the DAP protocol. I've seen a few instances with similar (mis)behavior. The same update that has the RTT support, uses TCP as a transport, and I have found it to be much more stable. It also has improved ability to catch host side RUST_LOG output, as well as target side logging via defmt. Are you OK to leave this issue open for a bit longer so that we can retest once that update has been merged?

noppej commented 3 years ago

  • Errors in extracting the location of local variables

  • Error when unwrapping any kind of option. (cant find file)

From the .config/cargo.toml file you sent ...

[target.'cfg(all(target_arch = "arm", target_os = "none"))'] runner = "probe-run --chip nRF52840_xxAA" rustflags = [ "-C", "linker=flip-link", "-C", "link-arg=-Tlink.x", "-C", "link-arg=-Tdefmt.x",

This is needed if your flash or ram addresses are not aligned to 0x10000 in memory.x

See https://github.com/rust-embedded/cortex-m-quickstart/pull/95

"-C", "link-arg=--nmagic",


I have not tested with either `flip-link` or `nmagic.x`

I will be able to try this after Wednesday, or else if you have time, feel free to try to test without those. Extracting location of variables depends on memory addresses in the binary, and I'm wondering if those libraries have a negative impact.

Another thing to try is to be explicit in `Cargo.toml`, with additional entries to force the level of debug info to compile into the binary.

[profile.dev] debug = 2 opt-level = 0

nihalpasham commented 3 years ago

If you are using VSCode's 'launch' mode, you can press the green anti-clockwise arrow "restart" button that shows up during a debug session. This will reset the probe, and start a new debug session.

I will add some documentation about this in the next update.

Yeah, I use VSCode's launch mode (i.e. GUI-based debugger). As I soon as press the reset arrow, my debugging session is dropped (i.e. VSCode completely exits debug mode).

nihalpasham commented 3 years ago

This hardly surprise me. Thanks for the additional description. The default 'launch' behavior for VSCode is to use STDIO as a transport for the DAP protocol. I've seen a few instances with similar (mis)behavior. The same update that has the RTT support, uses TCP as a transport, and I have found it to be much more stable. It also has improved ability to catch host side RUST_LOG output, as well as target side logging via defmt. Are you OK to leave this issue open for a bit longer so that we can retest once that update has been merged?

Noted. No hurries, would love to give it go when available - PS: for now, probe-run + defmt is my go-to tool for debugging (print-f style). It works better than pretty much everything I've used so far (that includes pyocd, openocd which feel quite flaky and unstable at times) !

nihalpasham commented 3 years ago

I have not tested with either flip-link or nmagic.x

I will be able to try this after Wednesday, or else if you have time, feel free to try to test without those. Extracting location of variables depends on memory addresses in the binary, and I'm wondering if those libraries have a negative impact.

Another thing to try is to be explicit in Cargo.toml, with additional entries to force the level of debug info to compile into the binary.

[profile.dev]
debug = 2
opt-level = 0

Ok, I'll try without flip-link or nmagic.x. On profile.dev - I usually do all my testing with release-builds for 2 reasons

But I'll try those settings to see if I get any new results.

noppej commented 3 years ago

  • last I checked (sometime back), dev-builds were apparently not reliable and the suggestion was to stick to release-builds

  • debug builds get pretty bloated and usually don't fit the amount of flash I've allocated in memory.x.

But I'll try those settings to see if I get any new results.

OK. In order to have breakpoints and resolve symbols, the debugger needs debug symbols emitted by the rustc compiler. You are welcome to experiment with various combinations as documented in https://doc.rust-lang.org/cargo/reference/profiles.html or https://doc.rust-lang.org/rustc/codegen-options/index.html

If you are trying options that you 'expect' to work based on the docs, but gives errors in the debugger, then please send me screenshots or logs of the exact errors, to help with tracking the root cause and fixing it :)

Yatekii commented 3 years ago

Note that technicallly, a debug build and debug symbols do not have to correlate. But ofc it is easier to create debug symbols for a debug build.

noppej commented 3 years ago

@nihalpasham Please can you check the updated guide, and install the latest version of the VSCode extension and probe-rs-debugger. I'd love to hear if this helps resolve some of your issues.

noppej commented 3 years ago

Closing due to a lack of activity. Please feel free to re-open after testing with latest release.