knurling-rs / probe-run

Run embedded programs just like native ones
Apache License 2.0
645 stars 75 forks source link

update to stm32h7xx-hal 0.11.0 and cortex-m-rt 0.7.1 breaks probe-run #316

Closed astraw closed 2 years ago

astraw commented 2 years ago

Describe the bug I am working on the knurling branch of rust examples for the nucleo-h743zi and nucleo-h743zi2 boards (direct link to knurling branch). I updated the nucleo code to take advantage of defmt and panic-probe and flashed an ran all this with probe-run and all worked great with the onboard STLINKv3 on my nucleo-h743zi2. Then I updated the Cargo.toml to use stm32h7xx-hal 0.11.0 (from 0.10.0) and cortex-m-rt 0.7.1 (from 0.6.15) and probe-run (0.3.3) now fails with Error: An error with the usage of the probe occured after reporting flashing the device successfully. Running with probe-run with -vv indicates that probe-run is wrongly choosing JTAG instead of SWD in this case.

There are the final lines before exit from the probe-run -vv:

(HOST) TRACE Sending command [f2, 3e] to STLink, timeout: 1s
└─ probe_rs::probe::stlink::usb_interface @ C:\Users\drand\.cargo\registry\src\github.com-1ecc6299db9ec823\probe-rs-0.12.0\src\probe\stlink\usb_interface.rs:215
(HOST) TRACE Read 12 bytes, 0 bytes remaining
└─ probe_rs::probe::stlink::usb_interface @ C:\Users\drand\.cargo\registry\src\github.com-1ecc6299db9ec823\probe-rs-0.12.0\src\probe\stlink\usb_interface.rs:281
(HOST) DEBUG Will clear HW breakpoint    #0 with comparator address    0x80002f8
└─ probe_rs::core @ C:\Users\drand\.cargo\registry\src\github.com-1ecc6299db9ec823\probe-rs-0.12.0\src\core\mod.rs:473
(HOST) TRACE write_mem_32bit
└─ probe_rs::probe::stlink @ C:\Users\drand\.cargo\registry\src\github.com-1ecc6299db9ec823\probe-rs-0.12.0\src\probe\stlink\mod.rs:927
(HOST) TRACE Sending command [f2, 8, 8, 20, 0, e0, 4, 0, 0] to STLink, timeout: 1s
└─ probe_rs::probe::stlink::usb_interface @ C:\Users\drand\.cargo\registry\src\github.com-1ecc6299db9ec823\probe-rs-0.12.0\src\probe\stlink\usb_interface.rs:215
(HOST) TRACE Wrote 4 bytes, 0 bytes remaining
└─ probe_rs::probe::stlink::usb_interface @ C:\Users\drand\.cargo\registry\src\github.com-1ecc6299db9ec823\probe-rs-0.12.0\src\probe\stlink\usb_interface.rs:257
(HOST) TRACE USB write done!
└─ probe_rs::probe::stlink::usb_interface @ C:\Users\drand\.cargo\registry\src\github.com-1ecc6299db9ec823\probe-rs-0.12.0\src\probe\stlink\usb_interface.rs:264
(HOST) TRACE Sending command [f2, 3e] to STLink, timeout: 1s
└─ probe_rs::probe::stlink::usb_interface @ C:\Users\drand\.cargo\registry\src\github.com-1ecc6299db9ec823\probe-rs-0.12.0\src\probe\stlink\usb_interface.rs:215
(HOST) TRACE Read 12 bytes, 0 bytes remaining
└─ probe_rs::probe::stlink::usb_interface @ C:\Users\drand\.cargo\registry\src\github.com-1ecc6299db9ec823\probe-rs-0.12.0\src\probe\stlink\usb_interface.rs:281
(HOST) TRACE Getting current mode of device...
└─ probe_rs::probe::stlink @ C:\Users\drand\.cargo\registry\src\github.com-1ecc6299db9ec823\probe-rs-0.12.0\src\probe\stlink\mod.rs:359
(HOST) TRACE Sending command [f5] to STLink, timeout: 1s
└─ probe_rs::probe::stlink::usb_interface @ C:\Users\drand\.cargo\registry\src\github.com-1ecc6299db9ec823\probe-rs-0.12.0\src\probe\stlink\usb_interface.rs:215
(HOST) TRACE Read 2 bytes, 0 bytes remaining
└─ probe_rs::probe::stlink::usb_interface @ C:\Users\drand\.cargo\registry\src\github.com-1ecc6299db9ec823\probe-rs-0.12.0\src\probe\stlink\usb_interface.rs:281
(HOST) DEBUG Current device mode: Jtag
└─ probe_rs::probe::stlink @ C:\Users\drand\.cargo\registry\src\github.com-1ecc6299db9ec823\probe-rs-0.12.0\src\probe\stlink\mod.rs:374
Error: An error with the usage of the probe occured

Caused by:
    Operation timed out
error: process didn't exit successfully: `probe-run --chip STM32H743ZITx -vv target\thumbv7em-none-eabihf\release\blinky` (exit code: 1)
PS C:\Users\drand\Documents\src\nucleo-h743zi> cargo run --release --bin blinky
    Finished release [optimized + debuginfo] target(s) in 0.05s
     Running `probe-run --chip STM32H743ZITx target\thumbv7em-none-eabihf\release\blinky`
(HOST) WARN  (BUG) location info is incomplete; it will be omitted from the output
(HOST) INFO  flashing program (7 pages / 7.00 KiB)
(HOST) INFO  success!
Error: An error with the usage of the probe occured

Caused by:
    Operation timed out
error: process didn't exit successfully: `probe-run --chip STM32H743ZITx target\thumbv7em-none-eabihf\release\blinky` (exit code: 1)

It seems with the older dependencies, probe-run correctly uses SWD but with the updated dependencies, it attempts to incorrectly use JTAG. Update 2022-04-02: in the working case I also see Current device mode: Jtag in the output, indicating that JTag is indeed used in the original working scenario.

Also, it seems possible that the bug is not with probe-run but with one of these other crates.

To Reproduce Steps to reproduce the behavior:

Install probe-run 0.3.3.

First observe error-free behavior:

git clone https://github.com/astraw/nucleo-h743zi --branch knurling
cd nucleo-h743zi
cargo run --release --bin blinky

Then update Cargo.toml to use stm32h7xx-hal 0.11.0 and cortex-m-rt 0.7.1. (This also updates the stm32h7 dependency from 0.13.0 to 0.14.0.) Re-run cargo run --release --bin blinky. Observe that probe run fails with Error: An error with the usage of the probe occured.

Expected and observed behavior I expected that probe-run would run without error. I observed the error mentioned above.

Probe details

probe-rs-cli list
The following devices were found:
[0]: STLink V3 (VID: 0483, PID: 374e, Serial: 0029002D3137511639383538, StLink)

Operating System: Windows

astraw commented 2 years ago

I also tried with the swd-protocol branch of probe-run installed from git and observed the same behavior.

kelleyk commented 2 years ago

I'm working with a Nucleo-H745ZI-Q board and the same versions of these libraries on a Linux host, and am seeing the same behavior.

astraw commented 2 years ago

Looking at the output of probe-run -vv in the original working case, I see Jtag is being used, there, too, so this is not the problem. I updated this aspect of my original comment.

astraw commented 2 years ago

With a bit more digging, the Operation timed out error is coming from core.wait_for_core_halted(Duration::from_secs(5))?; in fn set_rtt_to_blocking after setting a hardware breakpoint and running. So it seems something with stm32h7xx-hal version 0.11.0 or cortex-m-rt 0.7.1 changed behavior in a relevant way here.

astraw commented 2 years ago

So testing stm32h7xx-hal 0.11.0 with cortex-m-rt 0.6.15 shows this combination works fine. I think the culprit is thus cortex-m-rt 0.7 and I opened the issue https://github.com/rust-embedded/cortex-m/issues/426.

Urhengulas commented 2 years ago

With a bit more digging, the Operation timed out error is coming from core.wait_for_core_halted(Duration::from_secs(5))?; in fn set_rtt_to_blocking after setting a hardware breakpoint and running. So it seems something with stm32h7xx-hal version 0.11.0 or cortex-m-rt 0.7.1 changed behavior in a relevant way here.


https://github.com/knurling-rs/probe-run/blob/2dde31148ae8fe44a9e4397cea9142032237be95/src/main.rs#L212-L215

If we look at the lines you identified as the error location, it seems that the core never reaches the main_fn_address and therefore times out. So probably something in how we calculate the main_fn_address is wrong when using cortex-m-rt 0.7.


From skimming the cortex-m-rt changelog the only change which mentions the main fn is https://github.com/rust-embedded/cortex-m-rt/pull/278, "Mark main() with a C ABI", but I don't know if this could trigger this error.

astraw commented 2 years ago

As mentioned in the new issue I opened https://github.com/rust-embedded/cortex-m/issues/426, I identified the first problematic commit https://github.com/rust-embedded/cortex-m-rt/commit/1fd84a8fc5a02854b561b413fd5c828a2f798e03. This commit changes in the linker script link.x.in, but this gets out of my experience.

kelleyk commented 2 years ago

I've posted some details in https://github.com/rust-embedded/cortex-m/issues/426; starting from scratch using https://github.com/knurling-rs/app-template, the latest master and v0.11.0 release of the HAL work just fine with cortex-m == 0.7.4 and probe-run == {0.2.6, 0.3.3}.

I think that the issue is something to do with the BSP crates; or perhaps we needed to update memory.x (which is copied into the project from the HAL crate) when updating the HAL crate. In any event, it doesn't seem to be a problem with probe-run.

astraw commented 2 years ago

Thanks @kellyk. Indeed this is no bug in probe-run and I have fixed the nucleo-h743zi to use the latest cortex-m-rt (0.7.1) and confirm this works with probe-run. Closing the issue here. Further discussion should be at https://github.com/rust-embedded/cortex-m/issues/426.

Urhengulas commented 2 years ago

Thanks everyone for investigating this issue!