Update to probe-rs v0.31.0#619
Conversation
|
Windows test run: Seems happy! |
1320a8e to
c7722d9
Compare
| // 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(); |
There was a problem hiding this comment.
ah, I love the smell of fresh API design in the morning
| use std::thread; | ||
| use std::time::{Duration, Instant}; | ||
| use strum::VariantNames; | ||
| use strum::VariantNames as _; |
| { | ||
| bail!("USB link in use; is OpenOCD or another debugger running?"); | ||
| } | ||
|
|
There was a problem hiding this comment.
It looks like the Usb variant still exists, should we keep this block?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
| # | ||
| # 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. |
There was a problem hiding this comment.
Nit: linewrap this whole block?
| probe: &mut Box<dyn ArmProbeInterface + '_>, | ||
| ap: &ApAddress, | ||
| addr: u8, | ||
| probe: &mut Box<dyn ArmDebugInterface + '_>, |
There was a problem hiding this comment.
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.
|
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 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 |
We are actively looking into upgrading existing hardware (either by firmware update or hardware replacement). Manufacturing will see the greatest impact, as each loom will have to be replaced or modified. In the near future (July) there are other upgrades planned and it may make sense to lump all these things together. I think it is important that Humility releases continue to support CMSIS-DAP v1 until we have deployed all the necessary hardware upgrades. |
This is a big jump and hopefully some architecture rework will mean we can update faster as needed.
No description provided.