07:39 <Ralph[m]> so, turns out i was chasing the wrong thing... Ctrl+C is handled correctly in tests (with both `cargo test` and `cargo nextest run`). i now wrote a small test to check this.... (full message at <https://catircservices.org/_irc/v1/media/download/AZjr5y5LOTnfoY_L_VxKbZJIp48mw8gOfhN56JxgO86BK26YxQ6j1r2hyx3vnS4PqfWsgGq9yAlFM-7xrSG51nG_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9mWHB1VkNBSVlpVmpLRUNxU1lER2lFQlY>)

10:33 <DominicFischer[m> I discovered this Mutex crate recently https://crates.io/crates/mutex , just in case you want something more standard/existing

11:36 <SosthneGudon[m]> <DominicFischer[m> "I discovered this Mutex crate..." <- Oh, thanks for that. It doesn't look like it fully solves my issue it's probably the closest to what I want.

11:54 <JamesMunns[m]> <SosthneGudon[m]> "Oh, thanks for that. It doesn'..." <- I'm one of the writers of this, lmk if you have any questions.

12:04 <SosthneGudon[m]> Thanks!

13:07 <firefrommoonligh> I concur that RTIC isn't appropriate here. It works for most of the applications I've had, but it sounds like this is an exception. Regarding better mutexes: I will cheat. What I'm about to post is just a macro that does... (full message at

13:07 <firefrommoonligh> <https://catircservices.org/_irc/v1/media/download/ATRXQN2M2z35Q3XaLNfxZYG4SUt737zgQuveucfK54FWPOeFbmr8kI0OhNbCQalL_UUb1TLtrYM51dzsJ-Pna6-_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9Gc01qZHVsalpGbEVSTHlLcFpjUUJoSno>)

13:09 <firefrommoonligh> * I concur that RTIC isn't appropriate here. It works for most of the applications I've had, but it sounds like this is an exception. Regarding better mutexes: I will cheat. What I'm about to post is... (full message at <https://catircservices.org/_irc/v1/media/download/ASDCVpntqGdYtXRkZopffnVc5f1qPoVgif1l9BVsWDQUTEJWmW-ng3khpg9gUHMlyMNMkivIoSMomgc9mFWpZaO_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy90WFBORGJ2RmhFYWttdFhVUE1KQlFpQU4>)

14:44 <thejpster[m]> has anyone else observed that semihosting::process:exit(1) will cause probe-rs to quit, but also cause probe-rs to not print the final few messages in the defmt/RTT buffer (like, the reason why you're exiting the process...)?

15:04 <diondokter[m]> <thejpster[m]> "has anyone else observed that ..." <- I've not used semi hosting since 2020. I think a lot of people haven't. This could very well be a bug that's gone unnoticed

15:29 <thejpster[m]> panic-probe uses it

15:30 <thejpster[m]> And it’s been hiding my panic messages ;(

15:48 <RockBoynton[m]> by default yes, you have to enable a feature: https://docs.rs/panic-probe/1.0.0/panic_probe/#panic-messages

16:43 <thejpster[m]> I have the enabled

16:43 <thejpster[m]> * I have that enabled

16:44 <thejpster[m]> (I own that crate, btw)

16:44 <thejpster[m]> the issue is it prints a panic message over defmt, and then does a UDF instruction to trigger a UsageFault to trigger a HardFault to make probe-rs quit. And it does, but the panic message is still in the RTT buffer because the buffer is polled but a hardfault is an interrupt (AFAIU)

18:00 <KevinPFleming[m]> can it just wait until the panic message has been retrieved from the buffer before issuing the UDF?

18:06 <thejpster[m]> it could certainly wait for some period of time. I guess it could wait until the buffer was empty?

18:06 <thejpster[m]> or probe-rs could drain the defmt-buffer before printing the hardfault stack trace and quitting the program

18:06 <thejpster[m]> s/-//RTT /

18:23 <KevinPFleming[m]> yeah. waiting until empty seems right, there shouldn't be anything else in the application putting stuff into the buffer at that point.

18:55 <RockBoynton[m]> Is this why I sometimes don't actually see the panic message? I thought I was just holding it wrong lol

21:10 <thejpster[m]> I think I’m going to patch panic-probe and just add a delay.