knurling-rs / probe-run

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

Timeout on every second run #255

Closed folkertdev closed 2 years ago

folkertdev commented 3 years ago

Describe the bug Every second run of probe-run results in a timeout

    Finished dev [optimized + debuginfo] target(s) in 0.02s
     Running `probe-run --chip STM32WLE5JBIx target/thumbv7em-none-eabi/debug/pingpong --probe 001A00195553500720393256`
(HOST) INFO  flashing program (18.83 KiB)
(HOST) INFO  success!
Error: Operation timed out

When there is no timeout, the program runs just fine. It is consistently every second time that a timeout occurs.

To Reproduce Steps to reproduce the behavior:

For me, flash the supplied elf file to the device (in my case, an stm32wle). Every second time, this operation will timeout. The other time it will run just fine.

config.toml The contents of your project's .cargo/config.toml file

[target.'cfg(all(target_arch = "arm", target_os = "none"))']
runner = "probe-run --chip STM32WLE5JBIx"

rustflags = [
  "-C", "linker=flip-link",
  "-C", "link-arg=-Tlink.x",
  "-C", "link-arg=-Tdefmt.x",
  # This is needed if your flash or ram addresses are not aligned to 0x10000 in memory.x
  # See https://github.com/rust-embedded/cortex-m-quickstart/pull/95
  "-C", "link-arg=--nmagic",
]

[build]
target = "thumbv7em-none-eabi"   # Cortex-M4 and Cortex-M7 (no FPU)

[alias]
rb = "run --bin"
rrb = "run --release --bin"

Probe details You can get this information from probe-rs-cli. Your microcontroller must be connected to your PC / laptop when you run the command below.

Example:

[0]: STLink V3 (VID: 0483, PID: 374e, Serial: 001A00195553500720393256, STLink)

Operating System: Linux (mint 19)

ELF file (attachment)

pingpong.tar.gz

Additional context

@jamesmunns suggested that configurable timeouts/retries may be a solution here.

jonas-schievink commented 3 years ago

Does this also happen with cargo embed?

folkertdev commented 3 years ago

I'm not sure I understand. The flashing process always succeeds. Can cargo embed actually (attempt to) run the application? It's not clear how to do that from the --help message or the README

Urhengulas commented 2 years ago

Hi @folkertdev, yes, cargo-embed also runs the application and can e.g. connect to rtt. cargo-flash only flashes the program.

newAM commented 2 years ago

I am a little late to the party here, but I know what this issue is.

In probe-run versions prior to v0.2.5 you get behavior like this on the STM32WL. Updating probe-rs fixed that, so I opened #243, unfortunately the symptoms were very difficult to triage, and I had a solution in hand, so that issue has zero relevant details (sorry).


You should also know there is an outstanding bug with flashing binaries larger than 64k on the STM32WL with probe-run v0.2.5.

The fix is not yet in a probe-rs release, so it isn't very practical for probe-run to fix the issue at this point.


I keep an open issue here to track all the probe issues with the STM32WL: https://github.com/newAM/stm32wl-hal/issues/74

Quick fix for now, install my fork where I fixed all the STM32WL bugs: cargo install --git https://github.com/newAM/probe-run.git

Urhengulas commented 2 years ago

Thank you for sharing @newAM!

Urhengulas commented 2 years ago

Fixed by #285