<M9names[m]>
<SEGFAULT[m]> "does probe-rs work with those..." <- RP2040 uses multidrop DAP, it won't work with stlinkv2 firmware. Stlink v3 is locked to st chips, so it won't work with those either
<SEGFAULT[m]>
cool so what do I use?
<JoshuaFocht[m]>
JoshuaFocht[m]: 9names: will this work?
<M9names[m]>
It does work with cmsis-dap firmware like dap42 linked above
<SEGFAULT[m]>
what about an old jlink clone
<SEGFAULT[m]>
the old purple Ali special
agg has quit [Remote host closed the connection]
tschundler has quit [Remote host closed the connection]
flx has quit [Remote host closed the connection]
tschundler has joined #rust-embedded
<M9names[m]>
Should be fine I think? From memory it's a bit slow with probe-rs
<SEGFAULT[m]>
or alternative idea, is it possible to use embassy with the usb-bootloader on the pico
<M9names[m]>
Yes
<JoshuaFocht[m]>
i use do that with elf2uf2-rs
<SEGFAULT[m]>
OK what do I do
<M9names[m]>
Yeah, that or picotool works well
<SEGFAULT[m]>
last time i was active in embedded rust openOCD was still relevent
<M9names[m]>
probe-rs and an appropriate debugger is the best experience once you've got the setup done
<JoshuaFocht[m]>
run cargo install --locked elf2uf2-rs then in your .cargo/config.toml replace runner = "probe-rs run" with runner = "elf2uf2-rs -d"
<SEGFAULT[m]>
hold down the boot button and prey?
<JoshuaFocht[m]>
yep
<SEGFAULT[m]>
well it flashed
<SEGFAULT[m]>
it ain't blinking
<SEGFAULT[m]>
but its a start
<JoshuaFocht[m]>
That is how I did most of my flashing till my boot button fell of then I got a Raspberry Pi Debug Probe
<SEGFAULT[m]>
I guess I don't get RTT through the built in usb?
<JamesMunns[m]>
semihosting, in the year of our ferris 2025?
<JamesMunns[m]>
(I know it makes sense for qemu, not sure if there's an RTT library for non cortex-m things either, mostly just joking around here)
<thejpster[m]>
feel free to write me an RTT implementation for this proprietary debugger and this proprietary IDE :)
<thejpster[m]>
RTT is kind of cortex-m only right now. And only for SEGGER's official tools, and some open source ones. I don't see other commercial debugger vendors rushing to implement SEGGER's protocol.
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]>
RTT also works on risc-v
<thejpster[m]>
with which debugger?
<GrantM11235[m]>
I'm using the builtin esp32c3 debugger
<GrantM11235[m]>
With probe-rs
<thejpster[m]>
OK, I'd file that under "ESP32-C3" rather than RISC-V more broadly (which is just an instruction set and says nothing about how to remotely steal data from RAM)
<thejpster[m]>
but good to knwo
<thejpster[m]>
* but good to know
<JamesMunns[m]>
this seems like a weird line to draw :D
<JamesMunns[m]>
RTT is just a very bog standard ring buffer
<JamesMunns[m]>
any debugger that can peek and poke could do the same technique
<thejpster[m]>
host side, yes, absolutely
mabez[m] has joined #rust-embedded
<mabez[m]>
thejpster[m]: it also works on Xtensa, though the probe-rs impl isn't efficient
<mabez[m]>
(it blocks the system 😅 bus to write the rtt buffer, we can improve it, but no time atm)
<mabez[m]>
* (it blocks the system bus to write the rtt buffer 😅, we can improve it, but no time atm)
<thejpster[m]>
> any debugger that can peek and poke could do the same technique
<thejpster[m]>
That requires modifying the debugger though, or having a high-performance API to write a plug-in for it.
<thejpster[m]>
My point about "kinda cortex-m only" was not a technical one, merely an observation about the current state of Rust Embedded
<mabez[m]>
It definitely works well on RISC V though, at least as well as cortex m in my experience
<JamesMunns[m]>
and tbf, the tool support follows the users
<JamesMunns[m]>
definitely agree embedded rust is probably like 70% cortex-m, 29% risc-v, and 1% cr1901 on msp430 :D
<JamesMunns[m]>
but anyway, it's too late on a friday, sorry for being pedantic 🍻
<thejpster[m]>
77 people said Cortex-R, and no-one published a crate for it?
<thejpster[m]>
grumbles
<JamesMunns[m]>
the kind of folks who use cortex-r are not great at OSS, IMO.
<JamesMunns[m]>
save from you, it seems
<thejpster[m]>
oof
danielb[m] has joined #rust-embedded
<danielb[m]>
<mabez[m]> "(it blocks the system 😅 bus to..." <- it's worse, we need to block to READ 🤣
<thejpster[m]>
I think RP2350 does that in RISC-V mode because the debug access uses the same port as the Hazard3 CPU. Cortex-M33 core gets its own port.
<thejpster[m]>
note that probe-rs supports 2350 yet.
<JamesMunns[m]>
it seems like there are "favorite" branches that support it
<JamesMunns[m]>
just hasn't been polished enough to merge?
<thejpster[m]>
someone with the time to do it and a deep knowledge of the Arm Debug Interface Version 6 and how it differs to ADIv5.
<thejpster[m]>
yes, the branch is a copy-paste of the ADIv5 support.
<thejpster[m]>
it works but it's ugly
<thejpster[m]>
I have heard that someone has come up with the money to do it.
<JamesMunns[m]>
seems like "ship a meh version, maybe with some warning flags, iterate on it in anger when necessary" is better than "don't support", but it's not my project
<thejpster[m]>
I think probe-rs have enough to do without committing copy-pasta to their repo.
<thejpster[m]>
but yeah, not my project either.
<dngrs[m]>
<JamesMunns[m]> "80% cortex-m, 40% rv32, 23..." <- that's a lot of rv64 :o
<JamesMunns[m]>
dngrs[m]: yeah, I think there's a lot of "on linux" there, tbh
<JamesMunns[m]>
lotta popular rv64 chips eating up the mips/openwrt space
<thejpster[m]>
"this ticket machine running android is an embedded system" kidn of deal
<JamesMunns[m]>
or set top boxes, or access points, etc.
<dngrs[m]>
fair enough
<thejpster[m]>
set-top boxes should run RISC OS, obviously
<JamesMunns[m]>
In my most "let them eat cake" moment, I can suggest folks use poststation and picotool in lieu of probe-rs support, for now :D
<thejpster[m]>
anyway, good chat but I have to run.
<thejpster[m]>
https://github.com/ferrous-systems/cortex-r/pull/3 renames cortex-r-semihosting to arm-semihosting and adds the target detection code. Answers on a postcard (not via postcard) about what to call the crates given most of the good names have gone already.
Noah[m] has joined #rust-embedded
<Noah[m]>
rp2035 is mostly waiting on reviews afaik
<Noah[m]>
and ryan to find a minute to address them afaik
<Jubilee[m]>
<thejpster[m]> "how do you tell in a cfg! if you..." <- huh, does `cfg(instruction_set)` not work?
fsinger has quit [Ping timeout: 252 seconds]
fsinger has joined #rust-embedded
fsinger is now known as flx
hjeldin__[m] has joined #rust-embedded
<hjeldin__[m]>
heya, i'm having issues using probe-rs (but i guess the issue is not probe-rs) with a jlink host from a nucleo board and a custom stm32 board. apparently the communication between host and target works up until a certain point.... (full message at
<hjeldin__[m]>
* heya, i'm having issues using probe-rs (but i guess the issue is not probe-rs) with a jlink host from a nucleo board and a custom stm32 board. apparently the communication between host and target works up until a certain point.... (full message at
<thejpster[m]>
<Jubilee[m]> "huh, does `cfg(instruction_set)`..." <- Like, cfg(thumb) and cfg(arm)? I could try it.
<hjeldin__[m]>
<hjeldin__[m]> "heya, i'm having issues using..." <- well apparently the NRST pin was being held low. i need to learn to wire buttons correctly 😄
Foxyloxy has quit [Read error: Connection reset by peer]
Foxyloxy has joined #rust-embedded
<Jubilee[m]>
<thejpster[m]> "Like, cfg(thumb) and cfg(arm)? I..." <- no, we have an `instruction_set` attr. I believe it would have to be `cfg(instruction_set(arm::a32))`
petekubiak[m] has quit [Quit: Idle timeout reached: 172800s]