The webpage suggests the following:

# Don't know if your target is available
# and what it's name is?
cargo flash --list-targets

However, cargo flash does not know --list-targets (At least not v.0.8.0) but --list-probes.

I could not figure out how the current link to the installer script works, but it could just be replaced by a link to

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/probe-rs/probe-rs/releases/latest/download/probe-rs-installer.sh | sh

Describe the bug
In the library's quickstart documentation there is an outdated link pointing to a moved repository.

The "Downloading to flash" section currently reads

Any target that has a CMSIS-Pack can be converted into a probe-rs flash download target with our utility

with "utility" pointing to https://github.com/probe-rs/target-gen.

To Reproduce
Open the quickstart chapter in a browser.

Expected behavior
Above link (i.e. the term "utility") should point to https://github.com/probe-rs/probe-rs/tree/master/target-gen

The latest changes to Embed.toml are not yet reflected on https://probe.rs/docs/tools/cargo-embed/ While the page links to the newest default.toml, the in-line examples still use old syntax.

The documentation recommends Zadig to install a generic WinUSB driver for J-Link devices on Windows:
https://probe.rs/docs/getting-started/probe-setup/#windows-1

In my opinion, the J-Link Configurator should be the preferred tool since it is published by Segger and supports this functionality (it is also pretty easy to make mistakes with Zadig). In addition, J-Link Configurator is probably the easiest tool to use to restore the J-Link USB driver, should someone need to do so in the future.

This is the home page for the tool itself: https://www.segger.com/products/debug-probes/j-link/tools/j-link-configurator/
And a wiki article showing how to configure a probe to use WinUSB: https://wiki.segger.com/J-Link_on_Windows_ARM

Describe the bug
On https://probe.rs/docs/knowledge-base/troubleshooting/ it says you should write rttEnabled: true, but it's set outside of the object in the "coreConfigs" array which seems to be incorrect.

"configurations": [{
// SNIP...
"rttEnabled": true,
// SNIP...
"coreConfigs": [{
    // SNIP ...,
    "options": {
        "env": {
            "DEFMT_LOG": "Trace" // Trace, Debug, Info, Warn, Error
            }
        },
    }
],
"consoleLogLevel": "Console", //Console, Info, Debug

To Reproduce
Follow the documentation.

Additional context
The JSON in the docs doesn't have balanced open/close brackets. The lack of indentation doesn't help with making it clear what properties go inside what objects. The uppercase first letter in "Trace" is non-conventional for Rust (and as far as I can tell, not necessary?). I'm not sure if rttEnabled is actually supposed to be outside of coreConfigs, from looking at this it seems not?

Suggested fix
Something like this might be nicer

{
    "version": "0.2.0",
    "configurations": [{
        // SNIP...
        "coreConfigs": [{
            // SNIP ...,
            "options": {
                "env": {
                    "DEFMT_LOG": "trace" // trace, debug, info, warn, error
                }
            },
            "rttEnabled": true
        }],
        "consoleLogLevel": "Console" //Console, Info, Debug
    }]
}

Since the web has changed a lot, some links that were pointing to it may stop working and could be redirected to the new equivalent page/section, eg: https://probe.rs/docs/tools/vscode/ could be redirected to https://probe.rs/docs/tools/debugger/

The probe.rs website reports different dependent packages for Ubuntu compared to the README.md:

# probe.rs
sudo apt install -y pkg-config libusb-1.0-0-dev libftdi1-dev
# README.md
sudo apt install -y libusb-1.0-0-dev libftdi1-dev libudev-dev libssl-dev

• libssl-dev is a required dependency which provides access to openssl
• lib-udev is required by the libudev-sys crate

This was particularly painful for me because compiling code on my Raspberry Pi takes ~10 minutes, and I ended up recompiling code 3-4 installing missing dependencies.

I couldn't find the source code for probe.rs, but I'd be happy writing a PR for it if you could point me to the file.

Describe the bug
The documentation at https://probe.rs/docs/getting-started/installation/#installation says to install from source, run cargo install probe-rs-tools. However, this fails due to probe-rs/probe-rs#2613.

Since this issue is closed, a new release should be made with the fix in place, or the documentation should be updated to remove the suggestion to run cargo install probe-rs-tools, or it should add --locked to the normal release.

To Reproduce
Steps to reproduce the behavior:

1. Run cargo install probe-rs-tools or cargo install probe-rs-tools --force

Expected behavior
The software should install.

Desktop (please complete the following information):

• macOS Mojave

Additional context
The command cargo install probe-rs-tools --force --locked works. Omitting --locked causes the failure, but the documentation only says to include --locked when building the nightly version.