bmputil-cli 1.0.0 reports unhandled crash flashing some stlink/v2 clones #60

pololevu commented 2025年09月09日 01:12:46 +02:00 (Migrated from github.com)

I have a couple of cheap chinese STLink/V2 clones that have been flashed with BMP firmware, I've been doing this for some time (from Debian), previously with dfu-util and latterly with bmputil-cli. As far as I remember there were never any reported issues using dfu-util and indeed using bmputil-cli works for both dongles but while one completes the flash without errors, the other gives the errors copied below.

The flashed probe seems to work perfectly and I have updated it many times, ignoring the error message but thought I should report it.

Error: ------------[ ✂ cut here ✂ ]------------
Unhandled crash in bmputil-cli v1.0.0
0: hardware fault or protocol violation

Location:
src/bmp.rs:83

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⋮ 2 frames hidden ⋮
3: bmputil_cli::BmputilHook::build_handler::h3286ba777540986b
at /home/simon/tools/blackmagic-debug/bmputil/src/bin/bmputil-cli.rs:501
499 │ {
500 │ BmputilHandler {
501 > inner_handler: (*self.inner_hook)(error),
502 │ }
503 │ }
4: bmputil_cli::BmputilHook::into_eyre_hook::{{closure}}::h23ad25d0af9ef96a
at /home/simon/tools/blackmagic-debug/bmputil/src/bin/bmputil-cli.rs:512
510 │ pub fn into_eyre_hook(self) -> EyreHookFunc
511 │ {
512 > Box::new(move |err| Box::new(self.build_handler(err)))
513 │ }
514 │ }
⋮ 3 frames hidden ⋮
8: <T as core::convert::Into>::into::h377d1223711de835
at /home/simon/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/convert/mod.rs:761
759 │ U: From,
760 │ {
761 > /// Calls U::from(self).
762 │ ///
763 │ /// That is, this conversion is whatever the implementation of
9: bmputil::bmp::handle_detach_errors::h5d1f33173662f84f
at /home/simon/tools/blackmagic-debug/bmputil/src/bmp.rs:83
81 │ _ => {
82 │ warn!("Possibly spurious error from OS while rebooting probe: {}", err);
83 > Err(err.into())
84 │ },
85 │ },
10: bmputil::bmp::BmpDevice::reboot::h4c59d1a279bf7ddf
at /home/simon/tools/blackmagic-debug/bmputil/src/bmp.rs:464
462 │ // If the bootloader is not manifestation tolerant, we have to force matters with a DFU_DETACH
463 │ if !dfu_iface.manifestation_tolerant() {
464 > handle_detach_errors(dfu_iface.detach())?;
465 │ }
466 │ // If the bootloader will not automatically detach, we have to force matters by doing a USB reset
11: bmputil::flasher::Firmware::program_firmware::hb76086e0985262e1
at /home/simon/tools/blackmagic-debug/bmputil/src/flasher.rs:123
121 │
122 │ if progress_bar.position() == (self.length as u64) {
123 > device.reboot(dfu_iface)
124 │ } else {
125 │ Err(eyre!("Failed to flash device, download incomplete"))
12: bmputil::flasher::flash_probe::heb63ae71787ff4d2
at /home/simon/tools/blackmagic-debug/bmputil/src/flasher.rs:208
206 │ });
207 │
208 > firmware.program_firmware(&mut device)?;
209 │
210 │ // Programming triggers a probe reboot, so after this we have to get libusb to
13: bmputil_cli::update_probe::hb66e31aed4cd4746
at /home/simon/tools/blackmagic-debug/bmputil/src/bin/bmputil-cli.rs:354
352 │ };
353 │
354 > bmputil::flasher::flash_probe(cli_args, probe, file_name)
355 │ }
356 │
14: bmputil_cli::main::h0cce8335da3f0920
at /home/simon/tools/blackmagic-debug/bmputil/src/bin/bmputil-cli.rs:660
658 │ }
659 │ } else {
660 > update_probe(&cli_args, update_args, &paths)
661 │ }
662 │ },
15: core::ops::function::FnOnce::call_once::h343b1272b2dd4506
at /home/simon/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250
248 │ /// Performs the call operation.
249 │ #[unstable(feature = "fn_traits", issue = "29625")]
250 > extern "rust-call" fn call_once(self, args: Args) -> Self::Output;
251 │ }
252 │
16: std::sys::backtrace::__rust_begin_short_backtrace::h07aabb0c49a79344
at /home/simon/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/backtrace.rs:152
150 │ F: FnOnce() -> T,
151 │ {
152 > let result = f();
153 │
154 │ // prevent this frame from being tail-call optimised away
17: main
at :
18: __libc_start_call_main
at ./csu/../sysdeps/nptl/libc_start_call_main.h:58
19: __libc_start_main_impl
at ./csu/../csu/libc-start.c:360
20: _start
at :

Run with COLORBT_SHOW_HIDDEN=1 environment variable to disable frame filtering.

I have a couple of cheap chinese STLink/V2 clones that have been flashed with BMP firmware, I've been doing this for some time (from Debian), previously with dfu-util and latterly with bmputil-cli. As far as I remember there were never any reported issues using dfu-util and indeed using bmputil-cli works for both dongles but while one completes the flash without errors, the other gives the errors copied below. The flashed probe seems to work perfectly and I have updated it many times, ignoring the error message but thought I should report it. Error: ------------[ ✂ cut here ✂ ]------------ Unhandled crash in bmputil-cli v1.0.0 0: hardware fault or protocol violation Location: src/bmp.rs:83 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ⋮ 2 frames hidden ⋮ 3: bmputil_cli::BmputilHook::build_handler::h3286ba777540986b at /home/simon/tools/blackmagic-debug/bmputil/src/bin/bmputil-cli.rs:501 499 │ { 500 │ BmputilHandler { 501 > inner_handler: (*self.inner_hook)(error), 502 │ } 503 │ } 4: bmputil_cli::BmputilHook::into_eyre_hook::{{closure}}::h23ad25d0af9ef96a at /home/simon/tools/blackmagic-debug/bmputil/src/bin/bmputil-cli.rs:512 510 │ pub fn into_eyre_hook(self) -> EyreHookFunc 511 │ { 512 > Box::new(move |err| Box::new(self.build_handler(err))) 513 │ } 514 │ } ⋮ 3 frames hidden ⋮ 8: <T as core::convert::Into<U>>::into::h377d1223711de835 at /home/simon/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/convert/mod.rs:761 759 │ U: From<T>, 760 │ { 761 > /// Calls `U::from(self)`. 762 │ /// 763 │ /// That is, this conversion is whatever the implementation of 9: bmputil::bmp::handle_detach_errors::h5d1f33173662f84f at /home/simon/tools/blackmagic-debug/bmputil/src/bmp.rs:83 81 │ _ => { 82 │ warn!("Possibly spurious error from OS while rebooting probe: {}", err); 83 > Err(err.into()) 84 │ }, 85 │ }, 10: bmputil::bmp::BmpDevice::reboot::h4c59d1a279bf7ddf at /home/simon/tools/blackmagic-debug/bmputil/src/bmp.rs:464 462 │ // If the bootloader is not manifestation tolerant, we have to force matters with a DFU_DETACH 463 │ if !dfu_iface.manifestation_tolerant() { 464 > handle_detach_errors(dfu_iface.detach())?; 465 │ } 466 │ // If the bootloader will not automatically detach, we have to force matters by doing a USB reset 11: bmputil::flasher::Firmware::program_firmware::hb76086e0985262e1 at /home/simon/tools/blackmagic-debug/bmputil/src/flasher.rs:123 121 │ 122 │ if progress_bar.position() == (self.length as u64) { 123 > device.reboot(dfu_iface) 124 │ } else { 125 │ Err(eyre!("Failed to flash device, download incomplete")) 12: bmputil::flasher::flash_probe::heb63ae71787ff4d2 at /home/simon/tools/blackmagic-debug/bmputil/src/flasher.rs:208 206 │ }); 207 │ 208 > firmware.program_firmware(&mut device)?; 209 │ 210 │ // Programming triggers a probe reboot, so after this we have to get libusb to 13: bmputil_cli::update_probe::hb66e31aed4cd4746 at /home/simon/tools/blackmagic-debug/bmputil/src/bin/bmputil-cli.rs:354 352 │ }; 353 │ 354 > bmputil::flasher::flash_probe(cli_args, probe, file_name) 355 │ } 356 │ 14: bmputil_cli::main::h0cce8335da3f0920 at /home/simon/tools/blackmagic-debug/bmputil/src/bin/bmputil-cli.rs:660 658 │ } 659 │ } else { 660 > update_probe(&cli_args, update_args, &paths) 661 │ } 662 │ }, 15: core::ops::function::FnOnce::call_once::h343b1272b2dd4506 at /home/simon/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250 248 │ /// Performs the call operation. 249 │ #[unstable(feature = "fn_traits", issue = "29625")] 250 > extern "rust-call" fn call_once(self, args: Args) -> Self::Output; 251 │ } 252 │ 16: std::sys::backtrace::__rust_begin_short_backtrace::h07aabb0c49a79344 at /home/simon/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/backtrace.rs:152 150 │ F: FnOnce() -> T, 151 │ { 152 > let result = f(); 153 │ 154 │ // prevent this frame from being tail-call optimised away 17: main<unknown> at <unknown source file>:<unknown line> 18: __libc_start_call_main<unknown> at ./csu/../sysdeps/nptl/libc_start_call_main.h:58 19: __libc_start_main_impl<unknown> at ./csu/../csu/libc-start.c:360 20: _start<unknown> at <unknown source file>:<unknown line> Run with COLORBT_SHOW_HIDDEN=1 environment variable to disable frame filtering.

dragonmux commented 2025年09月09日 01:32:51 +02:00

Thank you for the report, may we presume from the paths that you're running on Linux?

Thank you for the report, may we presume from the paths that you're running on Linux?

pololevu commented 2025年09月09日 03:04:08 +02:00 (Migrated from github.com)

Yes, I use Debian testing.

Yes, I use Debian testing.

dragonmux commented 2025年09月10日 23:48:03 +02:00

Please give fix/linux-protocol-fault-suppression a shot and let us know how you get on - it should fix this issue.

Please give [`fix/linux-protocol-fault-suppression`](https://github.com/blackmagic-debug/bmputil/tree/fix/linux-protocol-fault-suppression) a shot and let us know how you get on - it should fix this issue.

pololevu commented 2025年09月11日 03:04:08 +02:00 (Migrated from github.com)

I can confirm that the fix is successful for the issue I reported, thank you. I tested by using "cargo build" and then "cargo run ..." which worked but gave 3 warnings about hiding a lifetime:

$ cargo run probe update ../blackmagic/build/blackmagic_stlink_firmware.bin
warning: hiding a lifetime that's elided elsewhere is confusing
--> src/bmp.rs:209:23
|
209 | pub fn serial_number(&self) -> Result<Ref>
| ^^^^^ -------- the same lifetime is hidden here
| |
| the lifetime is elided here
|
= help: the same lifetime is referred to in inconsistent ways, making the signature confusing
= note: #[warn(mismatched_lifetime_syntaxes)] on by default
help: use '_ for type paths
|
209 | pub fn serial_number(&self) -> Result<Ref<'_, str>>
| +++

warning: hiding a lifetime that's elided elsewhere is confusing
--> src/serial/remote/protocol_v1.rs:45:26
|
45 | pub(crate) fn interface(&self) -> MutexGuard
| ^^^^^ --------------------------- the same lifetime is hidden here
| |
| the lifetime is elided here
|
= help: the same lifetime is referred to in inconsistent ways, making the signature confusing
help: use '_ for type paths
|
45 | pub(crate) fn interface(&self) -> MutexGuard<'_, BmdRspInterface>
| +++

warning: hiding a lifetime that's elided elsewhere is confusing
--> src/serial/remote/protocol_v2.rs:44:26
|
44 | pub(crate) fn interface(&self) -> MutexGuard
| ^^^^^ --------------------------- the same lifetime is hidden here
| |
| the lifetime is elided here
|
= help: the same lifetime is referred to in inconsistent ways, making the signature confusing
help: use '_ for type paths
|
44 | pub(crate) fn interface(&self) -> MutexGuard<'_, BmdRspInterface>
| +++

warning: bmputil (lib) generated 3 warnings
Finished dev profile [unoptimized + debuginfo] target(s) in 0.12s
Running target/debug/bmputil-cli probe update ../blackmagic/build/blackmagic_stlink_firmware.bin

I can confirm that the fix is successful for the issue I reported, thank you. I tested by using "cargo build" and then "cargo run ..." which worked but gave 3 warnings about hiding a lifetime: $ cargo run probe update ../blackmagic/build/blackmagic_stlink_firmware.bin warning: hiding a lifetime that's elided elsewhere is confusing --> src/bmp.rs:209:23 | 209 | pub fn serial_number(&self) -> Result<Ref<str>> | ^^^^^ -------- the same lifetime is hidden here | | | the lifetime is elided here | = help: the same lifetime is referred to in inconsistent ways, making the signature confusing = note: `#[warn(mismatched_lifetime_syntaxes)]` on by default help: use `'_` for type paths | 209 | pub fn serial_number(&self) -> Result<Ref<'_, str>> | +++ warning: hiding a lifetime that's elided elsewhere is confusing --> src/serial/remote/protocol_v1.rs:45:26 | 45 | pub(crate) fn interface(&self) -> MutexGuard<BmdRspInterface> | ^^^^^ --------------------------- the same lifetime is hidden here | | | the lifetime is elided here | = help: the same lifetime is referred to in inconsistent ways, making the signature confusing help: use `'_` for type paths | 45 | pub(crate) fn interface(&self) -> MutexGuard<'_, BmdRspInterface> | +++ warning: hiding a lifetime that's elided elsewhere is confusing --> src/serial/remote/protocol_v2.rs:44:26 | 44 | pub(crate) fn interface(&self) -> MutexGuard<BmdRspInterface> | ^^^^^ --------------------------- the same lifetime is hidden here | | | the lifetime is elided here | = help: the same lifetime is referred to in inconsistent ways, making the signature confusing help: use `'_` for type paths | 44 | pub(crate) fn interface(&self) -> MutexGuard<'_, BmdRspInterface> | +++ warning: `bmputil` (lib) generated 3 warnings Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.12s Running `target/debug/bmputil-cli probe update ../blackmagic/build/blackmagic_stlink_firmware.bin`

dragonmux commented 2025年09月11日 03:07:38 +02:00

Yeah, unsure which version of the compiler that's from, but we're aware of that as an upcoming thing to solve - as long as we can fix it without upsetting stable, then we will for the next release. For now, we'll get the fix branch PR'd so that fix can land on main and inch things closer to a v1.1 release (or a v1.0.1 release if we backport it for expediency)

Yeah, unsure which version of the compiler that's from, but we're aware of that as an upcoming thing to solve - as long as we can fix it without upsetting stable, then we will for the next release. For now, we'll get the fix branch PR'd so that fix can land on `main` and inch things closer to a v1.1 release (or a v1.0.1 release if we backport it for expediency)

pololevu commented 2025年09月11日 03:10:53 +02:00 (Migrated from github.com)

Ok, sounds good. If it helps I'm using:

$ rustup check
stable-x86_64-unknown-linux-gnu - Up to date : 1.89.0 (29483883e 2025年08月04日)
rustup - Up to date : 1.28.2

Ok, sounds good. If it helps I'm using: $ rustup check stable-x86_64-unknown-linux-gnu - Up to date : 1.89.0 (29483883e 2025年08月04日) rustup - Up to date : 1.28.2