Closed laplab closed 1 year ago
In at attempt to get more information, I added a debug print of this dhcsr value read by probe-rs.
After this wait_for_core_halted
is called, the history of dhcsr values is the following (I explicitly mention "true" values, all others are false):
s_retire_st
and c_debugen
are set for a couple of iterationss_retire_st
, s_sleep
and c_debugen
are sets_sleep
and c_debugen
are setHope this helps.
Thank you for reporting. I don't have a pi pico w at hand to test it. Does it also occur with the pi pico (not W)?
I am afraid I only have Pico W at hand. If it helps, I am open to live debugging session over Zoom 🙂
I am afraid I only have Pico W at hand.
I might be able to get my hands on one. I will try.
If it helps, I am open to live debugging session over Zoom slightly_smiling_face
Let's keep this as an option!
Does it also occur with the pi pico (not W)?
I tested on two regular pico's (pico A debugging B, and B debugging A) and could not reproduce the issue. However, I created a custom board using RP 2040 and W25Q128JVSIQ
as flash (pico uses W25Q16JVUXIQ
) that does experience the exact same timeout in the exact same place (as far as I can tell).
I tested on two regular pico's (pico A debugging B, and B debugging A) and could not reproduce the issue. However, I created a custom board using RP 2040 and
W25Q128JVSIQ
as flash (pico usesW25Q16JVUXIQ
) that does experience the exact same timeout in the exact same place (as far as I can tell).
Thank you for your investigation. As far as I can read from the data sheets pico and pico 2 use the same flash, so I am not sure if the problem stems from there... 🤔
I'm also having this issue - using an RPi Pico H with DapperMime as a probe, debugging a custom RP2040-based board.
Are you using an RP2040 BSP, or do you have the RP2040 bootloader set up? The RP2040 doesn't boot like any other Cortex-M CPU and requires a second-stage bootloader. Please see https://github.com/rp-rs/rp2040-boot2 for more details. The HAL cannot include the bootloader because it varies depending on the Flash chip you have, which is why it is included in each of the various BSPs; or you can include it directly in your main.rs
.
@Urhengulas we should add a note to app-template that it doesn't work on the RP2040 and that they need to use an RP2040-based BSP, or otherwise include the Bootloader.
@jonathanpallant Adding the bootloader from https://github.com/rp-rs/rp2040-boot2 fixed the issue for me. Thank you so much!
Thank you Jonathan!
@laplab said:
@jonathanpallant Adding the bootloader from https://github.com/rp-rs/rp2040-boot2 fixed the issue for me. Thank you so much!
Great!
@jonathanpallant said:
@Urhengulas we should add a note to app-template that it doesn't work on the RP2040 and that they need to use an RP2040-based BSP, or otherwise include the Bootloader.
Yes. We can also refer to https://github.com/rp-rs/rp2040-project-template/ for that.
@jonathanpallant said:
Are you using an RP2040 BSP, or do you have the RP2040 bootloader set up?
I initially used a BSP to verify that two rp pico H boards could debug each other, then I manually setup the rp2040-boot2
bootloader with rp2040_boot2::BOOT_LOADER_W25Q080
to verify I was working was configuring the bootloader correctly without the help of the board crate.
Moving to my custom rp2040
based board I tried both rp2040_boot2::BOOT_LOADER_W25Q080
and rp2040_boot2::BOOT_LOADER_GENERIC_03H
(my flash is W25Q128JVSIQ
which was recommended in the "Hardware design with RP2040" pdf), which did not work
I was mainly working from the rp2040-project-template
repo linked above, but since I could not reproduce the issue on an rp pico H w/ either bootloader I assumed it must be a probe-run issue.
@Laura7089 what flash are you using? And did did the bootloader suggestion fix your issue?
Describe the bug
At attempt to run
hello
example from knurling-rs template results in an "Operation timed out" error.To Reproduce
cargo-generate
rp2040-hal = "0.6.0"
HAL andRP2040
for the--chip
argument ofprobe-run
. Also copy the memory.x file into the project root.cargo run --release --bin hello
Expected and observed behavior
Expected: program flashes the uf2, opens defmt session, displays "Hello, world!" and exits.
Observed:
config.toml
Probe details
Operating System:
macOS Monterey 12.4
ELF file (attachment)
hello.zip
Additional context
I have tried to get additional context on the issue before reporting it. I cloned probe-run and probe-rs repositories and accompanied some occurrences of
DebugProbeError::Timeout
error withpanic!
to get the origin of the error. Here is what I got when running modified version ofprobe-run
with-v
flag passed:After reading the probe-run code, I figured out that the hardware breakpoint set for the
main
function was not hit for some reason, since the timeout is coming from this line. At this point, I decided to create a Github Issue.