Unable to determine reset handler

[ilmai]

Describe the bug
Since updating to latest probe-run today, I'm getting this error when trying to run my RP2040 code.

To Reproduce
Steps to reproduce the behavior:

1. Run any RP2040 program with probe-run --chip RP2040 <path>

Expected and observed behavior
Expected probe-run to remain open while printing output from RP2040 as before.

Instead, getting this output:

(HOST) INFO  success!
Error: unable to determine reset handler

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

[target.thumbv6m-none-eabi]
runner = "probe-run --chip RP2040"
rustflags = [
    "-C", "linker=flip-link",
    "-C", "link-arg=--nmagic",
    "-C", "link-arg=-LUiFirmware",
    "-C", "link-arg=-Tdefmt.x",
    "-C", "link-arg=-Tlink.x",
    "-C", "inline-threshold=5",
    "-C", "no-vectorize-loops",
]

Probe details
[0]: Picoprobe CMSIS-DAP (VID: 2e8a, PID: 000c, Serial: E6614864D35F8C21, CmsisDap)

Operating System:
Linux running under WSL

Additional context
Like mentioned above, things worked as expected with the previous version.

[alexmoon]

I'm having the same issue on nRF52. I think it will happen for any firmware that does not have the reset vector in the elf file (i.e. any firmware using a bootloader, softdevice, etc).

[DusterTheFirst]

I am also facing this issue on the rp2040 with the latest release. Reverting to the previous version, the error goes away.

[dreamsmasher]

Facing the same issue on RP2040.

[alexmoon]

Incidentally, I've worked around the issue in my local install by replacing

probe-run/src/main.rs

Lines 486 to 490 in e6482fb

	let reset_symbol = match reset_symbols.len() {
	1 => reset_symbols.remove(0),
	_ => bail!("unable to determine reset handler"),
	};
	let reset_size = reset_symbol.size() as u32;

with:

    let reset_size = match reset_symbols.len() {
        1 => reset_symbols.remove(0).size() as u32,
        _ => 4,
    };

Stack unwinding fails after getting to the app entry point, but that doesn't bother me much. I doubt this is how the maintainers would want to address the issue, but it works for me and may be useful to others here.

[Ladvien]

Same issue here on rp2040.

[Urhengulas]

Sorry that this problem made it into the release.

Two questions:

1. Can one of you who faces this issue install probe-run from the following branch and report what they are seeing? I just added a log statement and made the failure modes more granular.

   $ cargo install --git https://github.com/knurling-rs/probe-run --branch debug-391

2. Is anyone aware of a method to determine the size of the reset handler, if it is not in the symbols? probe-run obtains the address of the reset handler in another way¹, but relies on the symbols for the size.

Footnotes

1. We read if from the program counter after a hard-reset ↩

[ilmai]

Sure thing, here's the output:

(HOST) INFO  success!
(HOST) INFO  reset_address=0xef
Error: unable to determine reset handler

[alexmoon]

On nrf52 with MBR, Softdevice, and bootloader:

(HOST) INFO  success!
(HOST) INFO  reset_address=0xa81
Error: unable to determine reset handler

I don't think it's possible to determine the size of the reset handler when it's not part of the application code. In my case, the reset handler is in the nRF MBR which then passes control to the bootloader which passes control to the Softdevice before control finally enters the entry point of my application. I don't think you can even assume that the stack is meaningful before reaching the app's entry point (e.g. a bootloader could choose to reset the stack before jumping to the app's entry point since the app is not supposed to ever return).

The current approach is probably fine for a best-effort type solution, but it shouldn't panic on failure.

[jonathanpallant]

As a work-around, if you wish to use probe-run on an RP2040, or a nRF chip with the soft-device, or anything else where the boot code isn't visible to probe-run, please use 0.3.6:

cargo install probe-run --version=0.3.6