probe-rs: ESP32-C3 error reading variable

Describe the bug The debugger sucessfully connects and can step through and pause breakpoints. But the variable values are not working.

Edit: Link to code

To Reproduce Steps to reproduce the behavior:

  1. Connect to cargo-embed with RTT off (due to #1221)
  2. Connect vscode to gdb (I am using this launch.json)
  3. Try to look at the value of a variable

Expected behavior The value of the variable is present without error

Stacktrace I get this in the variables list for my variable:

<error reading variable: Cannot access memory at address 0x3fccf608>
Screen Shot 2022-09-09 at 8 16 25 PM

Desktop (please complete the following information):

  • macOS Monterey (12.5.1)

Additional context I am on an arm64 mac (apple m1) and using the espressif-provided gdb

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 30 (30 by maintainers)

Most upvoted comments

Created #1230 and #1231

This should fix it, I deleted that branch after it got merged to esp-hal:

[patch.crates-io]
# Currently patching esp32c3-hal with a change to the linker script that makes defmt work.
esp32c3-hal = { git = "https://github.com/esp-rs/esp-hal", rev = "c896e6c8d2062dd9222508b55e23197c29f8e98f" }

That being said, even after doing this the code no longer produces any rtt info with cargo embed. I’m very confused, as this most definitely used to work. Here is my log:

warning: 11 warnings emitted

      Config monitor
      Target D:\Ryan\Programming\slimevr\rust\firmware\target\riscv32imac-unknown-none-elf\debug\firmware
        INFO cargo_embed > Protocol speed 0 kHz
        WARN probe_rs::config::target > Using custom sequence for ESP32c3
        INFO probe_rs::probe::espusbjtag > JTAG IDCODE: 0x00005c25
        INFO probe_rs::architecture::riscv::sequences::esp32c3 > Disabling esp32c3 watchdogs...
        INFO probe_rs::architecture::riscv                     > Discovered trigger with index 0 and type 2
        INFO probe_rs::architecture::riscv                     > Discovered trigger with index 1 and type 2
        INFO probe_rs::architecture::riscv                     > Discovered trigger with index 2 and type 2
        INFO probe_rs::architecture::riscv                     > Discovered trigger with index 3 and type 2
        INFO probe_rs::architecture::riscv                     > Discovered trigger with index 4 and type 2
        INFO probe_rs::architecture::riscv                     > Discovered trigger with index 5 and type 2
        INFO probe_rs::architecture::riscv                     > Discovered trigger with index 6 and type 2
        INFO probe_rs::architecture::riscv                     > Discovered trigger with index 7 and type 2
        WARN probe_rs::architecture::riscv                     > Breakpoint 0: Mcontrol { .0: 601882624, type_: 2, dmode: false, maskmax: 31, hit: false, select: false, timing: false, sizelo: 0, action: 0, chain: false, match_: 0, m: false, s: false, u: false, execute: false, store: false, load: false }
        WARN probe_rs::architecture::riscv                     > Breakpoint 1: Mcontrol { .0: 601882624, type_: 2, dmode: false, maskmax: 31, hit: false, select: false, timing: false, sizelo: 0, action: 0, chain: false, match_: 0, m: false, s: false, u: false, execute: false, store: false, load: false }
        WARN probe_rs::architecture::riscv                     > Breakpoint 2: Mcontrol { .0: 601882624, type_: 2, dmode: false, maskmax: 31, hit: false, select: false, timing: false, sizelo: 0, action: 0, chain: false, match_: 0, m: false, s: false, u: false, execute: false, store: false, load: false }
        WARN probe_rs::architecture::riscv                     > Breakpoint 3: Mcontrol { .0: 601882624, type_: 2, dmode: false, maskmax: 31, hit: false, select: false, timing: false, sizelo: 0, action: 0, chain: false, match_: 0, m: false, s: false, u: false, execute: false, store: false, load: false }
        WARN probe_rs::architecture::riscv                     > Breakpoint 4: Mcontrol { .0: 601882624, type_: 2, dmode: false, maskmax: 31, hit: false, select: false, timing: false, sizelo: 0, action: 0, chain: false, match_: 0, m: false, s: false, u: false, execute: false, store: false, load: false }
        WARN probe_rs::architecture::riscv                     > Breakpoint 5: Mcontrol { .0: 601882624, type_: 2, dmode: false, maskmax: 31, hit: false, select: false, timing: false, sizelo: 0, action: 0, chain: false, match_: 0, m: false, s: false, u: false, execute: false, store: false, load: false }
        WARN probe_rs::architecture::riscv                     > Breakpoint 6: Mcontrol { .0: 601882624, type_: 2, dmode: false, maskmax: 31, hit: false, select: false, timing: false, sizelo: 0, action: 0, chain: false, match_: 0, m: false, s: false, u: false, execute: false, store: false, load: false }
        WARN probe_rs::architecture::riscv                     > Breakpoint 7: Mcontrol { .0: 601882624, type_: 2, dmode: false, maskmax: 31, hit: false, select: false, timing: false, sizelo: 0, action: 0, chain: false, match_: 0, m: false, s: false, u: false, execute: false, store: false, load: false }
        INFO cargo_embed                                       > Initializing RTT (attempt 1)...
        INFO cargo_embed                                       > RTT initialized.
Shutting down.
        WARN probe_rs::session                                 > Could not clear all hardware breakpoints: ArchitectureSpecific(Timeout)

Could it be that I set too many breakpoints, and they are still saved on the hardware somehow? And probe-rs is having trouble clearing them (the last WARN)?

I’d like to see the launch.json do both the build and the flash

I did this once already, and then to save time I simply turned off flashing. But I can keep it on going forward while we debug this 😃

Any chance you can give me access to your repo, so that I can debug directly?

Sure, I should have posted that in the original github issue from the start. I’ve edited the first post with a link to the repo.

@TheButlah Are you open to testing this with the probe-rs-debugger and probe-rs extension for VSCode? That way we can determine where the issue lies, and if it is in the probe-rs libs, then it gives us the ability to debug to where exactly the problem lies.

  • Install the probe-rs-debugger extension in VS Code, by downloading the latest available probe-rs-debugger-x.x.x.vsix from the Releases page in our repo (we will publish to the Microsoft Extension marketplace when we exit the ‘Alpha’ phase of this project)

    • Install the downloaded extension file from the command line, for example: code --install-extension probe-rs-debugger-0.3.3.vsix in the terminal
  • Install the probe-rs-debugger server component, from the comand line with: cargo install --git https://github.com/probe-rs/probe-rs --force --branch master probe-rs-debugger

  • Instructions and samples for setting up launch.json are in the official docs

sure, this is with passing RUST_LOG=trace to cargo embed?