Probe-rs fails to work after first time use successful

embedded
1

I am new to rust and its ecosystem (but not to embedded programming in general, for which I have used C so far).

As a first step to try out the tools, I have compiled the "blinky" and "usb-serial" examples provided with "embassy" and ran them on an STM32F103.

Basically, I was able to start these using

cargo run --release

I also saw the debug info sent back to the host by the info! macros. So far so good!

Then, I interrupted the output with Ctrl-C.

The applications were still running on the target. I saw the LED blinking and the echo of data sent over the terminal of a computer attached to the USB serial port of my target board.

However, after that, I unfortunately am unable to re-connect to the target board.

Repeating the above command yields:

$ cargo run --release
    Finished release [optimized + debuginfo] target(s) in 0.09s
     Running `probe-rs run --chip STM32F103C8 target/thumbv7m-none-eabi/release/embassy-stm32f1-examples`
Error: Connecting to the chip was unsuccessful.

Caused by:
    0: An ARM specific error occurred.
    1: The debug probe encountered an error.
    2: An error specific to a probe type occurred
    3: Command failed with status SwdApFault

So I am unable to re-flash the software.

I disconnected and re-connected the power to my target, and to my STLink adapter, but this did not help.

Probe-rs "sees" the STLink,

$ probe-rs list
The following debug probes were found:
[0]: STLink V2 (VID: 0483, PID: 3748, Serial: 51C3BF700649C2865256154105C287, StLink)

On one hand, I would like to re-connect to see the info! macro messages sent over the SWD interface, as before I hit Ctrl-C, but don't know how to do that. I tried probe-rs attach (the manual says "This is great for inspecting a target - where you might not even have knowledge of the firmware - without altering its state." but attach nevertheless asks for the path to an ELF file... I don't understand this).

What can I do to resolve this?

2

are you able to erase the flash using other software such as OpenOCD?

this looks like a debug port lock out I would guess.

you should point it at target/target-arch-triplet/debug/blinky, because defmt need the debug symbol to decode the data frames, the message you see on the terminal are not plain text, but preprocessed compressed binary encoding, which need to be decoded.

3

Ok, I understand. I tried this, but when I interrupt the output with Ctrl-C and then reconnect, I get the following error:

$ cargo run
    Finished dev [optimized + debuginfo] target(s) in 0.09s
     Running `probe-rs run --chip STM32F103C8 target/thumbv7m-none-eabi/debug/stm-uart-test`
     Erasing sectors ✔ [00:00:02] [############################################################] 40.00 KiB/40.00 KiB @ 17.86 KiB/s (eta 0s )
 Programming pages   ✔ [00:00:02] [############################################################] 40.00 KiB/40.00 KiB @ 13.45 KiB/s (eta 0s )    Finished in 5.242s
0.000000 TRACE BDCR ok: 00008200
└─ embassy_stm32::rcc::bd::{impl#2}::init @ /xxx/embassy/embassy-stm32/src/fmt.rs:117 
0.000000 DEBUG rcc: Clocks { sys: Hertz(48000000), pclk1: Hertz(24000000), pclk1_tim: Hertz(48000000), pclk2: Hertz(48000000), pclk2_tim: Hertz(48000000), hclk1: Hertz(48000000), adc: Some(Hertz(6000000)), rtc: Some(Hertz(40000)) }
└─ embassy_stm32::rcc::set_freqs @ /xxx/embassy/embassy-stm32/src/fmt.rs:130 
0.000000 INFO  Hello World!
└─ stm_uart_test::____embassy_main_task::{async_fn#0} @ src/main.rs:30  

(... output deleted ...)

11.292327 TRACE READ WAITING, buf.len() = 64
└─ embassy_stm32::usb::usb::{impl#10}::read::{async_fn#0} @ /xxx/embassy/embassy-stm32/src/fmt.rs:117 
^C

After the Ctrl-C, I re-attach and reproducibly get this:

$ probe-rs attach --chip STM32F103C8 ./target/thumbv7m-none-eabi/debug/stm-uart-test
DEBUG probe_rs::debug::unit_info: Found DIE, now checking for inlined functions: name=None
Frame 0: <unknown function @ 0x08001430> @ 0x08001430
       /xxx/embassy/embassy-executor/src/arch/cortex_m.rs:106:21
Frame 1: __cortex_m_rt_main @ 0x08001402
       /xxx/stmtest/src/main.rs:22:1
Frame 2: __cortex_m_rt_main_trampoline @ 0x080013ec
       /xxx/stmtest/src/main.rs:22:1
Frame 3: <unknown function @ 0x08000112> @ 0x08000112
Frame 4: <unknown function @ 0x08000112> @ 0x08000112
Error: CPU halted unexpectedly.

The only way I found to attach is by holding down the reset button of the target while reattaching, and only then releasing the button. But then of course I cannot connect to a running instance.

Not sure, maybe that is the way this is intended to work?

I think I made some progress.

The communication seems to only lock up when I flash the rust programs. When I flash these and then unpower both the STLink and the target, and reconnect both, neither probe-rs nor openocd are able to flash the target except when I manually hold down the reset button on the board and only release it once probe-rs or openocd run.

When flashing my "normal" C firmware, this problem does not occur. Then, even after a fresh power-up, I am able to flash with either openocd or probe-rs.

So it seems the rust code sets the swd interface into a state in which the communication with the host no longer works.

This is annoying since in the boards I develop I normally do not have reset buttons...

Is there a way out of this?

4

I'm not familiar with embassy, but I don't think should be like this, at least from my expeirence probe-rs and defmt-rtt both can attach to running target, maybe it's a embassy specific configuration.

I believe it's nothing to do with C or rust, but likely an embassy specific thing. again, since I don't have the knowledge about embassy to look into it, I can only guess, I see a link to a matrix chat channel on their website, maybe you'll get better and quicker information there.

you can do a quick check to decide if the problem is with embassy or with probe-rs or something else, for example, you can try to flash or debug your C code via probe-rs, also try to build and run rust code without embassy, for example, use the bare metal stm32-hal crate directly, or maybe try an alternative to embassy (such as rtic) if you want RTOS-like infrastructure. you may need to adjust some of the configs of the examples to fit your specific soc/board model.

5

It turned out that the problem was that embassy puts the controller into sleep mode (which I knew), and that apparently it is not possible connect to it using SWD in this state (which was unclear to me).

I could solve this by wiring the NRST line from the STLINK to my target, and by adding --connect-under-reset as argument to probe-rs.