Rust in Everything
基于 probe-rs-tools 0.32.0

Error: No connected probes were found.

主线位置：命令主线第二步「选探针」。probe-rs run 在 attach、烧录之前，先发一个 probe/select 请求让服务端枚举探针；列表为空就是这个报错。机制见一条 probe-rs run 和 DebugProbe 与驱动注册表。

flowchart TB
  cmd["run、download、info、cargo flash"] --> sel["probe/select：Lister 问每个驱动"]
  sel -->|"0 个"| err["NoProbesFound：No connected probes were found."]
  sel -->|"1 个"| open["打开它"]
  sel -->|"多个"| ask["终端里选序号"]
  open -->|"没有权限"| perm["打开失败：另一个报错"]
  gdb["gdb --dry-run"] --> sa["simple_attach：FakeProbe"]
  sa --> ok["不选探针，起 GDB 服务端"]

现象

本机没有探针。四个常用入口，同一句话：

$ cargo run --release
     Running `probe-rs run --chip STM32L475VGTx <target>/thumbv7em-none-eabihf/release/defmt-demo`
Error: No connected probes were found.
$ probe-rs run --dry-run --chip STM32L475VGTx fw.elf
Error: No connected probes were found.
$ probe-rs info --dry-run
Could not attach to target. Try running with --verbose for more information about the target.
Error: No connected probes were found.
$ cargo flash --chip STM32L475VGTx --path fw.elf
    Flashing fw.elf
       Error No connected probes were found.
$ probe-rs list
No debug probes were found.

probe-rs run 的退出码是 1；list 不算错误，退出码 0。

从哪来

报错文字是 OperationError::NoProbesFound 的 Display（common_options.rs:495）。走 RPC 的命令里，它由服务端的 select_probe 在列表长度为 0 时返回：

// probe-rs-tools/src/bin/probe-rs/rpc/functions/probe.rs
    let mut list = lister.list_with_access(request.probe.map(|sel| sel.into()).as_ref());
    // ...
    match list.len() {
        0 => Err(OperationError::NoProbesFound.into()),
        1 => Ok(SelectProbeResult::Success(with_interface(
            DebugProbeEntry::from(list.swap_remove(0)),
        ))),
        _ => Ok(SelectProbeResult::MultipleProbes(/* ... */)),
    }

Lister 让 DRIVERS 表里的每个驱动枚举自己认得的 USB 设备（DebugProbe 与驱动注册表）。所以「零个」的意思很窄：没有一个驱动在 USB 上认出自己的设备。几种常见原因：

情形为什么是零个
没插，或用的是只供电不传数据的线USB 上根本没有设备
探针固件不在任何驱动的认领范围里比如 VID / PID 不在表里，或者是插件提供的驱动而插件没注册（库用户的情形，见找不到 esp32c3）
给了 --probe VID:PID[:序列号] 而写错了选择器把列表过滤空了
Windows 上没装对驱动cargo-flash 的提示里专门写了 J-Link 要用 Zadig 装驱动（下文）；本卷没有 Windows 环境，未核实

权限问题通常不是这一条。 list_with_access 的文档写明：「Probes that cannot be accessed are still included, marked Accessibility::PermissionDenied」（probe/list.rs:109）。Linux 上没装 udev 规则时探针仍会出现在列表里，失败发生在下一步「打开」，报的是另一个错误。这是按源码推断的，本卷没有 Linux 加探针的环境，待实测。

--dry-run 为什么没用

run、download、info 都有 --dry-run，但它在服务端的 attach_probe 里才被看到，而客户端在发 probe/attach 之前已经发了 probe/select，后者不看 dry_run（一条 probe-rs run）。所以这三个命令的 --dry-run 在没有探针时一律失败在选探针上。真正生效的只有 probe-rs gdb --dry-run：它不走 RPC，simple_attach 直接调 attach_probe，换上 FakeProbe（gdb server）。

gdb --dry-run 也有边界：选 nRF52 系列会 panic 在「No more operations expected」，因为 nRF 的调试序列要读 CTRL-AP，而 FakeProbe 只有预先登记的应答才答得上来；--connect-under-reset 则撞上 todo!()。这些是 FakeProbe 的限制，不是用户的错（FakeProbe）。

提示去哪了

源码里有两套「找不到探针时的提示」：

  • 命令行公用的 print_setup_hints：只在 Linux 上编译进去，打三行 warn 日志，指向 udev 规则的文档；环境变量 PROBE_RS_DISABLE_SETUP_HINTS 可以关掉。本机是 macOS，所以上面的输出里没有。
  • cargo-flash 自己的 render_diagnostics：对 NoProbesFound 准备了 Linux udev、Windows 驱动、探针设置指南三条提示。

后者在实验里一条也没出现。原因是错误穿过了 RPC：cli::attach_probe 返回的是 anyhow::Error，转成 OperationError 时落进的是 Anyhow(#[from] anyhow::Error) 这个透明变体，而不是 NoProbesFound，诊断表按变体匹配，于是只打印错误本身。这是「本地也走 RPC」的一个小代价（设计取舍）。

怎么办

  1. 先跑 probe-rs list。它列不出来，问题在 USB 或驱动，和芯片、固件、--chip 都无关。
  2. 列得出来但 run 失败，看报错是不是换了：权限问题、多个探针（非交互模式下报「N probes were found」）、选择器写错。
  3. 只是想在没有硬件时走一遍流程：gdb --dry-run 是命令行里唯一有效的 dry-run；更完整的办法是在库里用 FakeProbe，或者自己实现一个探针（写一个软件探针）。

小结

  • 「No connected probes were found.」只说明 Lister 一个设备也没认出来，发生在 attach 之前，和芯片、固件无关。
  • 没权限的探针仍会被列出，失败在打开那一步，报的是别的错（按源码推断，待实测）。
  • run、download、info 的 --dry-run 在没有探针时没用，只有 gdb --dry-run 真的换上 FakeProbe。
  • Linux 才有安装提示；cargo-flash 的诊断提示因为错误穿过 RPC 变成了 anyhow，实际不会出现。

💬 关联讨论

发起讨论
加载中...