Skip to content

Update to probe-rs v0.31.0#619

Open
labbott wants to merge 3 commits into
masterfrom
probe-rs-v0.31.0
Open

Update to probe-rs v0.31.0#619
labbott wants to merge 3 commits into
masterfrom
probe-rs-v0.31.0

Conversation

@labbott
Copy link
Copy Markdown
Contributor

@labbott labbott commented Apr 16, 2026

No description provided.

@labbott labbott marked this pull request as draft April 16, 2026 12:43
@sdonnan
Copy link
Copy Markdown
Contributor

sdonnan commented Apr 16, 2026

Windows test run:

PS E:\stuart\working\humility> git log -1 --oneline
02547623 (HEAD -> probe-rs-v0.31.0, origin/probe-rs-v0.31.0) WIP: hold my beer I want to update probe-rs

PS E:\stuart\working\humility> cargo run --release -- lsusb
    Finished `release` profile [optimized + debuginfo] target(s) in 0.65s
     Running `target\release\humility.exe lsusb`
humility: USB device scan, 2 successful and 6 failed
humility: --- successfully opened devices ---
humility: format: VID:PID:SERIAL, then manufacturer name, then product name
humility: 046d:c628:(serial unknown)    3Dconnexion     SpaceNavigator for Notebooks
humility: 38c6:0001:000000803b5a95305d5cc175fa18799758892acd4c504355    Oxide   CMSIS-DAP v1
humility: --- failures ---
humility: could not access 6 devices:
... snip ...

PS E:\stuart\working\humility> cargo run --release -- probe
    Finished `release` profile [optimized + debuginfo] target(s) in 0.64s
     Running `target\release\humility.exe probe`
humility: attached via CMSIS-DAP V2 IF: 4 DESC: Some(InterfaceAltSetting { interface_number: 4, alternate_setting: 0, num_endpoints: 2, class: 255, subclass: 0, protocol: 0, string_index: Some(9), endpoints: [Endpoint { address: 0x05, direction: Out, transfer_type: Bulk, max_packet_size: 512, packets_per_microframe: 1, interval: 0 }, Endpoint { address: 0x85, direction: In, transfer_type: Bulk, max_packet_size: 512, packets_per_microframe: 1, interval: 0 }] })
humility:        probe => OxLink (CMSIS-DAP), VID 38c6, PID 0001
humility: probe serial => 000000803b5a95305d5cc175fa18799758892acd4c504355
humility:         core => Cortex-M7
humility: manufacturer => STMicroelectronics
humility:         chip => STM32H7, revision 0x2003
humility:       status => executing, debug halt
humility:  debug units => CSTF(x2) CTI(x2) DWT ETM FPB ITM SCS SWO TMC TPIU
humility:         CSTF => 0x5c004000, 0x5c013000
humility:          CTI => 0x5c011000, 0xe0043000
humility:          DWT => 0xe0001000
humility:          ETM => 0xe0041000
humility:          FPB => 0xe0002000
humility:          ITM => 0xe0000000
humility:          SCS => 0xe000e000
humility:          SWO => 0x5c003000
humility:          TMC => 0x5c014000
humility:         TPIU => 0x5c015000
humility:           R0 => 0x24078900
humility:           R1 => 0x24078900
humility:           R2 => 0x0
humility:           R3 => 0x0
humility:           R4 => 0x0
humility:           R5 => 0x0
humility:           R6 => 0x0
humility:           R7 => 0x240788f8
humility:           R8 => 0x0
humility:           R9 => 0x0
humility:          R10 => 0x0
humility:          R11 => 0x0
humility:          R12 => 0x0
humility:           SP => 0x240788f8
humility:           LR => 0x805fd6f
humility:           PC => 0x805fd74
humility:          PSR => 0x61000000
humility:          MSP => 0x240003b0
humility:          PSP => 0x240788f8
humility:          SPR => 0x7000000

Seems happy!

@labbott labbott force-pushed the probe-rs-v0.31.0 branch from fce004e to fbe787d Compare May 18, 2026 16:53
@labbott labbott changed the title WIP: update to probe-rs v0.31.0 Update to probe-rs v0.31.0 May 18, 2026
@labbott labbott marked this pull request as ready for review May 18, 2026 17:28
@labbott labbott force-pushed the probe-rs-v0.31.0 branch from fbe787d to 4632566 Compare May 21, 2026 18:44
@labbott labbott requested review from cbiffle, hawkw and mkeeter May 21, 2026 18:48
// Get a list of all available debug probes.
let probes = Probe::list_all();
let list = probe_rs::probe::list::Lister::new();
let probes = list.list_all();
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, I love the smell of fresh API design in the morning

Comment thread cmd/rendmp/src/lib.rs
use std::thread;
use std::time::{Duration, Instant};
use strum::VariantNames;
use strum::VariantNames as _;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

spooky

Comment thread humility-probes-core/src/lib.rs Outdated
{
bail!("USB link in use; is OpenOCD or another debugger running?");
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like the Usb variant still exists, should we keep this block?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We now get back a raw std::io::Error which does not have downcast_ref, only downcast (https://doc.rust-lang.org/stable/std/io/struct.Error.html) and it was faster to just pull it out when I was doing the upgrade. It wasn't clear if there was still value in keeping it. Looking again, the flow of this entire function is weird so I'm going to take a pass to see if I can make it more reasonable.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did some tweaks and I think I brought it back. I'm still not clear on the value but if we run into more errors that need better messages we can add more.

Comment thread humility-probes-core/src/lib.rs Outdated
Comment thread humility-probes-core/src/lib.rs Outdated
Comment thread humility-probes-core/src/lib.rs Outdated
Comment thread humility-probes-core/src/probe_rs.rs Outdated
Comment thread humility-probes-core/src/probe_rs.rs Outdated
Comment thread Cargo.toml
#
# We depend on the oxide-stable branch of Oxide's fork of probe-rs to assure
# that we can float necessary patches on probe-rs.
# that we can float necessary patches on probe-rs.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: linewrap this whole block?

probe: &mut Box<dyn ArmProbeInterface + '_>,
ap: &ApAddress,
addr: u8,
probe: &mut Box<dyn ArmDebugInterface + '_>,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wondered if we could remove the Box here (in favor of a &mut dyn ArmDebugInterface), but poking at it shows that it would ripple through a bunch of places, so out of scope for this PR.

labbott added 2 commits May 22, 2026 01:32
This is a big jump and hopefully some architecture rework will mean
we can update faster as needed.
@labbott
Copy link
Copy Markdown
Contributor Author

labbott commented May 22, 2026

This discussion may need to go elsewhere but I'm putting it here for now:

One of the advantages of updating to a newer probe-rs is we can avoid a dependency on libusb and just use the native Rust nusb library. The catch is this only works with CMSIS-DAP v2 probes. Our out of the box MCULinks are running old firmware and only support CMSIS-DAP v1 which uses the hidapi crate which is secretly libusb . We've had to do some hacks to make this work (see #202 and #466). Some options here:

A) We allow using CMSIS-DAP v1 probes and continue supporting HID via libusb. I do not love this option because 1) We've had problems with hid/libusb in the past and we'll have to continue with our hacks 2) We'll now have to deal with a potential mixture of CMSIS-DAPv1 and CMSIS-DAP v2 probes and two different libraries to debug.

B) We require all MCULinks to be updated to CMSIS DAP v2 firmware. I didn't catch this issue initially because I had already done so. We have reliable instructions on how to do this https://github.com/oxidecomputer/meta/blob/master/engineering/mculink-upgrade.md , the downside is we will need to make sure this happens across our fleet of probes in the lab and manufacturing.

C) We use OxLink which comes with updated CMSIS-DAP firmware and works great.

I expect we will want some combination of B & C depending on how fast we can produce OxLinks . I am not a fan of A.

As far as I can tell this is a concern only for MCULinks not STLinks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants