02:41 <ian_rees[m]> I'm trying to track down a really strange bug on SAMD51 (Cortex M4): with a minimal firmware that just sets up a 100MHz CPU clock (hardware defaults to 48MHz) and does loop { cortex_m::asm::delay(100_000_000); defmt::debug!("Tick"); }, the speed of the log output sometimes runs 3-48 slower depending on enabling what I'd think are completely unrelated Cargo features. The only thing I think the features should change in this

02:41 <ian_rees[m]> firmware is the presence of some global statics. Any ideas on what to look for?

02:41 <ian_rees[m]> s//`/, s/,/`,/, s/48/4x/

02:46 <ian_rees[m]> So far, I've ruled out a difference in the clock tree, it actually does generate a 100MHz clock in either condition. Though it's interesting that in the slow condition the clock does seem a bit unstable in frequency - see https://github.com/atsamd-rs/atsamd/issues/819#issuecomment-2774752035 for some spectra of the normal/slow clocks

06:46 <ivmarkov[m]> I'm trying to shrink the `.rodata` section as much as possible (by using `defmt`). I've wrapped all (most?) of my `panic!`s and `.unwraps` using their `defmt` equivalents. Yet what I'm observing is that `.rodata` still contains tons of file locations. It is as almost as if `defmt::panic!` calls `core::panic!` which would then capture this info (in the absence of `panic_immediate_abort`).

06:46 <ivmarkov[m]> The question is, am I missing something, or is it really that `defmt::panic!` (and friends) do call into `core::panic!`, and why would that be?

06:46 <ivmarkov[m]> Given that `defmt::panic!` and so on are printing an error message with `defmt::error!`, can't these just generate some sort of trap, rather than calling `core::panic!`

09:00 <ivmarkov[m]> <ivmarkov[m]> "I'm trying to shrink the `...." <- To answer my own question: no `defmt` works _just fine_ w.r.t. calling `core::panic!` as it does it by **not**-inlining the call to `core::panic!` and hiding it behind a global function. I replaced that function with another (with `avoid-default-panic`) which just does `loop {}` and the path strings are still there, in `.rodata`. Most likely (checking this ATM) these path strings

09:00 <ivmarkov[m]> in `.rodata` come from array bounds' checks and overflow checks, which there is no way for `defmt` to currently intercept and fix.

09:00 <ivmarkov[m]> If that turns out to be true, bloat due to bounds-checking and overflow-checking can only be removed with p-i-a, I guess :(.

09:07 <ivmarkov[m]> * and overflow-checking (update: overflow checking can, * can be disabled with overflow-checks = false) can only be

16:42 <JamesMunns[m]> CC @adamgreig, @therealprof, I've written up a second update of what I think the Rust Society could look like.... (full message at <https://catircservices.org/_irc/v1/media/download/AR6LRU1edZcQsodSkjJHWKdvj97yYz3VTCyLKZ0IokZIixJSaLS9V835TszoX7myxuSTNnc7NrJmNA29tH_qJPa_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy90UHFLTGVGVnRMcmlibGNuZVBtbE12ck8>)

18:21 <phcoder_cat[m]> Hello, all. I try to experiment with Rust in GRUB. I have 2 problems right now. First one is that -Zregparm=3 doesn't change call convention used by memcpy calls from Rust. Second one is that some platforms use stdcall and other ones use cdecl calling convention. So I wanted to be able to do something like unsafe extern grubcall!() .... rather than declaring every function twice. But when I try to do with the macro I get an

18:21 <phcoder_cat[m]> error: "expected `fn`"

18:46 <GuineaWheek[m]> has anyone successfully gotten dcache on an stm32h7 to work with the ethernet peripheral

19:20 <GuineaWheek[m]> every time i try to use the mpu to not cache sram3 i just get unaligned access hard faults

19:33 <adamgreig[m]> Huh, weird to get unaligned access issues. I've definitely had h7 with dcache and mpu disabling caching on sram3 for ethernet dma buffers working before

19:33 <adamgreig[m]> Long time ago though

20:54 <balbi[m]> <JamesMunns[m]> "CC @adamgreig, @therealprof, I'..." <- wooo, typst!

20:58 <JamesMunns[m]> balbi[m]: Yeah I've been enjoying it!

20:59 <dngrs[m]> <phcoder_cat[m]> "Hello, all. I try to experiment..." <- your error is cut off at "expected `fn`", there should be a somewhat more verbose output, can you paste it in full? also potentially the piece of code triggering the error? (I probably won't be able to help you, but more context is useful to have)

20:59 <JamesMunns[m]> balbi[m]: https://github.com/jamesmunns/rust-society/blob/main/reports/src/2025-04-04.typ

20:59 <JamesMunns[m]> Also in source form :)

21:11 <balbi[m]> <JamesMunns[m]> "https://github.com/jamesmunns/..."; <- I should make full switch at some point. After 20+ years on LaTeX it's a little harder.

21:14 <JamesMunns[m]> balbi[m]: I never learned latex, which made the switch easier for me :D

22:26 <GuineaWheek[m]> <adamgreig[m]> "Huh, weird to get unaligned..." <- yeah so it seems that whenever the sram3 gets handed to smoltcp as a &[u8] smoltcp does an unaligned access and this causes a fault

22:27 <GuineaWheek[m]> whats more mysterious is why configuring the mpu causes unaligned accesses to fail to begin with

22:33 <adamgreig[m]> yea I think there's something misleading going on there. how do you know it's an unaligned access?