ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
sroemer has joined #rust-embedded
sroemer has quit [Quit: WeeChat 4.5.2]
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
<JamesMunns[m]> Yeah part of the trick is that all interrupts/exceptions in cortex-m switch back to the MSP, which means if thread mode is using the PSP you can fiddle with it in interrupt context so when you return you return elsewhere
<JamesMunns[m]> so you could safely call something like svcall, but you'd need to do unsafe trickery to change the return location in the svcall handler
korken89[m] has quit [Quit: Idle timeout reached: 172800s]
rainingmessages has joined #rust-embedded
pcs38 has joined #rust-embedded
Ralph[m] has quit [Quit: Idle timeout reached: 172800s]
<dngrs[m]> What are my (HW and SW) options for HS USB host these days? SW wise I've been eyeing cotton, but embassy also seems to be making forays?
pcs38 has quit [Quit: leaving]
jackwilsdon[m] has joined #rust-embedded
<jackwilsdon[m]> From what I can tell probe-rs isn't catching the hard fault that panic-probe is triggering. Not really clear as to why (just using the Raspberry Pi Debug Probe).
<jackwilsdon[m]> Looks like it's this: https://github.com/probe-rs/probe-rs/issues/3194
<jackwilsdon[m]> Appears it was fixed only recently and hasn't been released yet.
<jackwilsdon[m]> * Looks like it's this: https://github.com/probe-rs/probe-rs/issues/3194
<jackwilsdon[m]> I'm using `probe-rs run` but it sounds like it has the same issue unless you pass the catch flag.
<jackwilsdon[m]> Appears it was fixed only recently and hasn't been released yet.
ouilemur has quit [Quit: WeeChat 4.6.2]
<jackwilsdon[m]> Right so adding --catch-hardfault on probe-rs 0.27.0 does print a stack trace but it's completely wrong.
danielb[m] has joined #rust-embedded
<danielb[m]> incorrect how?
<danielb[m]> * wrong how?
<jackwilsdon[m]> s/`/`:/, s/(which//, s/is running `probe-rs run --chip RP2040 --protocol swd --catch-hardfault`)://
<jackwilsdon[m]> I'd expect to see main in there at least. Not really sure how delay.rs has ended up in there either (this line specifically: https://github.com/rust-embedded/cortex-m/blob/master/cortex-m/src/delay.rs#L40)
<danielb[m]> technically main is there ERROR panicked at src/main.rs:74:9: šŸ˜…
<danielb[m]> yeah I'm not fluent enough in ARM to debug this, but there were some changes done since the last release that you might try (by installing probe-rs from git).
<jackwilsdon[m]> I did just try the git version (c7d65ad813b55bd7e44bb6c7b4f3596a384b1da6 from today) but it's actually worse 😭... (full message at <https://catircservices.org/_irc/v1/media/download/AWdN_Ut7EFtgL-AMjZTSTiKZXYkd-a1fGxR-heIYtLZLw84Wm-zrRYIDPZXCbMCqXxjsMGuXC9qK1jUiQX66BMy_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9qWHR0c2RGVXRTamhsaHlPbkFwbUxvamQ>)
<jackwilsdon[m]> s/Compiling rp2040-project-template v0.1.0 (/home/jack/Development/rp2040-panic-issue)//
<danielb[m]> hmm add --always-print-stacktrace please
<danielb[m]> awesome, thanks
<jackwilsdon[m]> I can raise an issue on GitHub if that helps?
<danielb[m]> I'll 100% forget this next week, so if you'd open an issue that would be helpful
<jackwilsdon[m]> Are there 2 issues? One that it's requiring always-print-stacktrace to print the stack trace on an unexpected halt and the other that the stacktrace is not right.
<jackwilsdon[m]> Or is it expected that it no longer prints a stacktrace?
<danielb[m]> I'd consider this a regression
<danielb[m]> (for the record, it was probably me who broke it)
<jackwilsdon[m]> At least you're owning up to it šŸ˜‰
<danielb[m]> i might get to that part of the issue today, but no promises
ouilemur has joined #rust-embedded
RobinMueller[m] has quit [Quit: Idle timeout reached: 172800s]
pcs38 has joined #rust-embedded
patrickh[m] has quit [Quit: Idle timeout reached: 172800s]
sroemer has quit [Ping timeout: 260 seconds]
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
sroemer has quit [Quit: WeeChat 4.5.2]
U007D[m] has quit [Quit: Idle timeout reached: 172800s]
KevinPFleming[m] has quit [Quit: Idle timeout reached: 172800s]
ragarnoy[m] has joined #rust-embedded
<ragarnoy[m]> Hey, it's the first time i use raspberry picos, if you don't have access to swd pins do you have to use the bootloader by drag and dropping the file ? or is there a way to use probe-rs or some other tool
<jackwilsdon[m]> If you don't have a debug probe or access to the debug pins, you need to use the USB UF2 upload yeah.
<jackwilsdon[m]> If you use `elf2uf2-rs -d` it'll automatically copy it to the mounted disk
<jackwilsdon[m]> I think picotool load can do it without mounting the disk, but it still need to be in BOOTSEL mode and plugged in over USB.
<jackwilsdon[m]> s//`/, s//`/, s/./ (and you need a `uf2` which can be generated with `elf2uf2-rs` or `picotool uf2 convert`/
<jackwilsdon[m]> s//`/, s//`/, s/./ (and you need a `uf2` which can be generated with `elf2uf2-rs` or `picotool uf2 convert`)/
<jackwilsdon[m]> Actually picotool load might be able to use the raw elf file from its documentation, but I've never tried it.
<jackwilsdon[m]> s//`/, s//`/, s/elf/ELF/
<JamesMunns[m]> it can
<JamesMunns[m]> runner = "picotool load -x -t elf"
<JamesMunns[m]> I use picotool for both the rp2040 and rp2350, when not using probe-rs
<JamesMunns[m]> same command will work for both
<danielb[m]> technically one core could debug the other, right?
<JamesMunns[m]> danielb[m]: yeah, I've seen projects that run a gdbstub on one core, which you can use to debug the other one
<ragarnoy[m]> Then how do you get the defmt logs from it ?
<JamesMunns[m]> I have no idea, practically
<ragarnoy[m]> also are elf2uf2 and picotool basically the same ?
<JamesMunns[m]> ragarnoy[m]: they do similar things
<JamesMunns[m]> picotool is actually published/maintained by the raspberry pi folks themselves
<JamesMunns[m]> for a while, elf2uf2 didn't support rp2350, I think it might now?
<ragarnoy[m]> <JamesMunns[m]> "for a while, elf2uf2 didn't..." <- from what i can see there's a pr open to add support
<ragarnoy[m]> well if anyone has experience with debugging an rp2350 and knows how to see the defmt logs i'm all ears
<thejpster[m]> elf2uf2-rs does one thing picotool does (make UF2 files and optionally copy them somewhere). Picotool does about 10 additional things (such as sign images)
<JamesMunns[m]> oh, I think someone made a usb defmt impl? not sure
<JamesMunns[m]> I really need to make that defmt sink for postcard-rpc...
<JamesMunns[m]> https://github.com/jamesmunns/postcard-rpc/issues/103 if you want to follow
<JamesMunns[m]> I often use postcard-rpc for usb comms, with no debugger attached. You can send whatever topics you want over postcard-rpc, which I typically use instead of defmt
<JamesMunns[m]> you can also add a "go to bootloader" command, so you can tell the app to go back to bootloader for reflashing
<thejpster[m]> ragarnoy[m]: As someone who has debugged a 2350 whilst looking at defmt logs (and before probe-rs had support) I’m pretty sure I used their openocd fork, which has RTT support.
<JamesMunns[m]> that still requires a probe, which the original commenter said they didn't have IIRC
<JamesMunns[m]> or rather, they don't have access to the swd pins
<ragarnoy[m]> JamesMunns[m]: i have probes but the rp i have is really limited in terms of pins
ManuelHatzl[m] has joined #rust-embedded
<ManuelHatzl[m]> ragarnoy[m]: if you are able to use openocd, I created embedded-runner which shows defmt logs in your console and writes them to a json file if you run tests.
<ManuelHatzl[m]> github.com/mhatzl/embedded-runner
<ragarnoy[m]> <thejpster[m]> "As someone who has debugged a 23..." <- whose fork?
<thejpster[m]> Raspberry Pi's fork
<thejpster[m]> https://www.waveshare.com/img/devkit/RP2350-ETH/RP2350-ETH-details-1.jpg - if you're wondering where the 2350 is, it's on the other side.
<thejpster[m]> Totally wild that they didn't break out the SWD pins. They are dedicated pins - there's nothing else you can do with them.
<thejpster[m]> Also, UART to Ethernet? Wild. Most people go for a Wiz5500 or one of those Microchip ENC things.
Koen[m] has joined #rust-embedded
<Koen[m]> Maybe because uart is async, so the phy can stream bytes directly to the Pi without buffering
<dngrs[m]> waveshare have a tendency to skip SWD on their smaller modules. with some determination and magnet wire this can be alleviated...
<ragarnoy[m]> <dngrs[m]> "waveshare have a tendency to..." <- yeah, that's on me, i'm so used to stm32s that i just thought swds were a given
jason-kairos[m] has quit [Quit: Idle timeout reached: 172800s]
zeenix[m] has quit [Quit: Idle timeout reached: 172800s]
pcs38 has quit [Quit: leaving]
ivche_ has joined #rust-embedded
ivche has quit [Ping timeout: 252 seconds]
ivche_ is now known as ivche