07:24 <Kaspar[m]> Is there a way to get a backtrace on hardfault on cortex-m with probe-rs? The backtrace stops one frame after the hardfault handler (in an unknown function), so that seems corrupted. I did try enabling "force-frame-pointers", and rebuilding core.

07:29 <Darius> does the hard fault handler do anything strange?

07:29 <Darius> some debuggers (eg the blackmagic probe) let you capture fault vectors which is good for this

07:32 <Darius> try --catch-hardfault

08:16 <Ralph[m]> i by chance saw James Munns's suggestion [here](https://github.com/jamesmunns/postcard-rpc/pull/97/files#r2021202132) that the serial number of the USB device should come from the device itself. i now... (full message at <https://catircservices.org/_irc/v1/media/download/AZN60wlKR3_lwig4fmUved6tNoRz_ytm7n3ZXjD0aL8NY3eVnlh74W2hKtbu6qcVjmlyNKkxeiwp7QZtNOhB-0i_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9CSFJ4VmFZWVZ0cUNuZkhtZUpBTkpDVVQ>)

08:26 <JamesMunns[m]> https://github.com/OneVariable/poststation-util/blob/main/templates/rp2040/src/main.rs#L46-L65

08:26 <JamesMunns[m]> Ralph ^

08:30 <Ralph[m]> thanks! but ugh... that looks painful!

08:32 <Ralph[m]> _maybe_ it'd be an option to take a number as an input in either prpc or prpc and embassy-usb and do this there? (to be honest: i have no clue how prevalent serial numbers in numeric format are across different MCUs, so this might purely be RP2040 specific and different for all others?)

08:32 <Ralph[m]> i think i'll just leave mine hardcoded at `Some("1")` for now (it's an internal thing with a single device deployed. if it'd have been easy, simple & clean code i'd have quickly thrown it in to follow best practices)

08:34 <JamesMunns[m]> My code is not clean enough 😭

08:34 <adamgreig[m]> in embassy-stm32 i wrote this thing to get a static str: https://github.com/embassy-rs/embassy/blob/main/embassy-stm32/src/uid.rs#L9

08:35 <adamgreig[m]> so in stm32 you can just call embassy_stm32::uid::uid_hex() and you're done, whcih is what I pass to embassy-usb

08:36 <adamgreig[m]> maybe something similar could be added to embassy-rp?

08:36 <Ralph[m]> adamgreig[m]: hm, i'm wondering if we could move the num-to-hex part to a more central `embassy-*` crate and then re-use it in others (e.g. `embassy-rp`)?

08:37 <JamesMunns[m]> It's a bit more complicated on rp2040, because the chips don't have unique id numbers, so you need to ask your external flash

08:37 <JamesMunns[m]> (Which can be of varying length, tho at least 64 bits is pretty common)

08:50 <Ralph[m]> <JamesMunns[m]> "My code is not clean enough 😭" <- sorry 😅

08:50 <Ralph[m]> what i meant was "if there's a single API i can call to get the value i want and feed that to the consumer i'll take it. but i'm not gonna add a dozen lines to my code if i don't actually really need a unique serial number since i'm not going to ship it"

08:51 <Ralph[m]> another question: the prpc examples use "Van Ooijen Technische Informatica... (full message at <https://catircservices.org/_irc/v1/media/download/AbpIC8qrP7S1pp1G7QWIoPxa3coA9I0eMVIRFTPOyaLqI9WJ2p30WiAvZ4KxkpXiMyNGW6nx7ElgzKz-HhZZdja_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy91cWFsbnV6V0RsdEtEaVhDdVN0TVNBRmQ>)

09:09 <JamesMunns[m]> Yeah, I didn't have a better vid/pid, it's probably the same one from the embassy-usb examples

09:36 <JamesMunns[m]> btw, starting to triage the state of the Postcard Cinematic Universe, feel free to follow along here: https://github.com/jamesmunns/postcard/issues/241

10:26 <Ralph[m]> <JamesMunns[m]> "btw, starting to triage the..." <- i see you mention "ergot" on there and i've seen you mentioning it here before. and i found [your repo](https://github.com/jamesmunns/ergot) with the following README:

10:26 <Ralph[m]> > This is a repo just for messing around. There are many other like it, but this is the q2 2025 attempt

10:26 <Ralph[m]> i still don't understand what it is / should be 😅

10:27 <JamesMunns[m]> Ralph[m]: it's a network stack that handles addressing and routing, and in the future might serve as the base for postcard-rpc, or supercede postcard-rpc: https://docs.rs/ergot/latest/ergot/#purpose

10:30 <Ralph[m]> JamesMunns[m]: ah, that helps a lot to understand things, thanks! i didn't realise that it was already on crates.io (based on the README i expected it to just be a repo for now). and i see that you got infected by fungi as well, that seems to be taking over 🤣

11:17 <dngrs[m]> commercial USB devices often put nonsense serial numbers, I've seen 0x123456 and also a lot of just "this space intentionally left blank" iirc

11:22 <thejpster[m]> Serial numbers are optional but if you have one it must be unique, otherwise Windows gets confused (or XP did, haven’t checked since) if you plug two devices in.

11:22 <thejpster[m]> Without a serial number, it would reinstall the driver every time it was plugged into a new usb port (because the path to the port was used as the unique ID instead when there’s no serial).

11:22 <wassasin[m]> Vendor ID is 'just' 6000 USD

11:23 <wassasin[m]> * 6000 USD https://www.usb.org/getting-vendor-id

11:29 <reto[m]> <wassasin[m]> "Vendor ID is 'just' 6000 USD" <- but for open source hardware you can get a PID via here: https://pid.codes/

11:29 <dngrs[m]> reto[m]: now that looks interesting

11:34 <Ralph[m]> <reto[m]> "but for open source hardware you..." <- ah, cool! so that's the "generic" VID 0x1209 which i've found before 👍️

12:02 <mkj[m]> or https://www.usb.org/sites/default/files/obsoletevids_10232019.pdf is a convenient list

12:06 <Ralph[m]> mkj[m]: oh, so "pick an obsolete vendor" is of course also a convenient option 👍️

12:06 <Ralph[m]> browsing the list and i just found this: "Nebraska Furniture Mart"... why would they make USB devices? in a B-rate movie that'd be some NSA outfit making spy devices 🤣

12:09 <mkj[m]> 0x1209 is on the list too, so they're all good enough!

12:20 <dngrs[m]> four seasons total USB

12:39 <Ralph[m]> <mkj[m]> "0x1209 is on the list too, so..." <- i missed the fact that the list is in decimal while everything else always uses hex for this... doh!

12:39 <Ralph[m]> <dngrs[m]> "four seasons total USB" <- where'd you spot that one 😮

12:39 <dngrs[m]> Ralph[m]: I made it up!

12:40 <Ralph[m]> <JamesMunns[m]> "btw, starting to triage the..." <- there's no issue for this yet, but you might want to add "update to upcoming `embassy-usb` release" to the list (no issue/PR yet because it hasn't been released yet - PR for that still pending with embassy)

12:41 <Ralph[m]> also: thanks for all your work on postcard/postcard-rpc!

15:33 <Ralph[m]> i'm running some HIL tests where the HIL test is running on linux and talking to the DUT (which runs stock firmware). i implemented the tests as normal rust tests (i.e. you can run `cargo test`).... (full message at <https://catircservices.org/_irc/v1/media/download/AcAUkboa3VznrLRWpDn60G5OQyPdezx_xt-7jPAa9PouXw_QZGxAwdNvAsEEro4cv4wibkZphYCf_CcDHqBhVyW_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9pd2NWRXB6Y3BkQlRZb1RxbFFsenNxSFI>)

15:36 <JamesMunns[m]> Does ctrl-c halt the firmware with probe-rs? Or do you mean the Drop impls on the desktop are not being run?

15:37 <JamesMunns[m]> If you mean on the desktop, I'm going to GUESS that cargo test has some kind of signal handler for control-c that then aborts the program, rather than unwinding test threads

15:37 <JamesMunns[m]> https://github.com/rust-lang/rust/issues/83326 sort of hints at this I think?

15:43 <dngrs[m]> there's https://crates.io/crates/ctrlc

15:43 <dngrs[m]> haven't used it in tests tho

15:44 <dngrs[m]> <JamesMunns[m]> "If you mean on the desktop, I'..." <- it's kind of the other way round, there is *no* special handler and as a result the process is just killed (the crate I linked resolves this by adding said handler)

15:45 <dngrs[m]> s/*no*/_no_/, s/killed/terminated/

15:46 <dirbaio[m]> You cant make a thread spontaneously start unwinding on control+c

15:46 <dirbaio[m]> The thread has to voluntarily check for control+c periodically and unwind itself

15:47 <dirbaio[m]> For example with async you can use sekect() together with Tokio signals

15:48 <dirbaio[m]> But even then it will only cancel. Itself at await points

15:48 <dngrs[m]> yeah, probably better to use async tests, otherwise it's gonna add a lot of boilerplate

15:48 <dirbaio[m]> If your code is blocking there's no way to do it

15:49 <dngrs[m]> you can check between blocking statements

15:49 <dngrs[m]> unpleasant but it is an option

15:50 <dirbaio[m]> Yeah, I mean it's not possible to externally cause blocking code to unwind

15:50 <dngrs[m]> anything is possible with w+x memory!

15:50 <dirbaio[m]> Like, "cargo test" doesn't unwind on control+c because it has no way to cause blocking test code to unwind without collaboration

15:51 <dirbaio[m]> This is why it just aborts

15:52 <Ralph[m]> i was talking about a desktop app, not embedded tests. i use tokio (i.e. async, multi-threaded) tests and i actually do `select!` on `tokio::signal::ctrl_c()` just as i do in the `bin` (basically i can use 1:1 the same code in the bin & the test but the `impl Drop` only gets executed in the bin while it seems that it just outright kills the test without dropping anything :(

15:52 <dirbaio[m]> Okay.. That's probably because the test runner's control+c handler is still running

15:53 <dirbaio[m]> IIRC the test runner runs multiple processes, maybe the control+c is going to the parent which is then killing the children violently?

15:55 <Ralph[m]> yeah, looks like it. i was hoping that that wouldn't be the case... it feels odd? i can't be the only one who wants to run the drop handlers in that case? (and i was hoping that others might be found here with the same issue since putting hardware back into a "safe" state after (failed/aborted) tests seems like a common requirement?)

15:59 <dirbaio[m]> I guess Making tests speak to external hardware is rare...

16:00 <dirbaio[m]> And for tests that are software-only, you definitely don't want a buggy test make control+c not work

20:22 <therealprof[m]> <Ralph[m]> "i by chance saw James Munns's..." <- Leak it?