00:09 <thalesfragoso[m]> <adamgreig[m]> "Huh, weird to get unaligned..." <- Didn't we explicit ask people to place it somewhere specific?

00:11 <adamgreig[m]> not sure where you mean exactly but sram3 is generally the preferred location for ethernet dma buffers in h7

00:11 <adamgreig[m]> but you need to mark sram3 as non-cacheable in the mpu

00:12 <thalesfragoso[m]> Hmm, found the issue:

00:12 <thalesfragoso[m]> https://github.com/stm32-rs/stm32-eth/issues/16

00:13 <thalesfragoso[m]> Basically yeah, somewhere non-cacheable, but there we suggest SRAM2, which iirc is non-cacheable by default.

00:13 <adamgreig[m]> on h7 sram3 is better I think, and stm32-eth doesn't support h7 so won't be what's used here

00:13 <adamgreig[m]> but yea, same deal exactly

00:13 <adamgreig[m]> unaligned access faults don't make sense though, smoltcp does byte access which can't be aligned

00:14 <adamgreig[m]> so I guess the error is being interpreted wrong and it's probably some other access fault due to mpu settings

00:15 <adamgreig[m]> (the ref man for h7 specifically suggests sram3 for ethernet and usb buffers, and those peripherals can directly master the bus to sram3)

00:24 <thalesfragoso[m]> Indeed, just remembered that we didn't support h7 there, and instead the HAL did.

00:26 <adamgreig[m]> yea, different peripheral, st finally paid synopsys for a new licence i guess

00:27 <thalesfragoso[m]> Still synopsys though, heh. I wonder if they finally added a DMB to their HAL driver.

03:37 <thalesfragoso[m]> If I have two nested ldrex and strex to the same address, does the inner one succeed?

07:50 <thejpster[m]> <ian_rees[m]> "I'm trying to track down a..." <- is it the clock speed that’s changing or the number of instructions per loop in asm::delay? IIRC it’s fairly crude. Certainly in debug mode it’ll be calling a nop function instead of inlining it. I wonder if we shouldn’t just write it in assembly.

08:19 <RobinMueller[m]> Does anyone here know how to retrieve RTT content from a SEGGER JLink GDB server? It mentions that I can use telnet port 19021, but I don´t get any output when trying `nc localhost 19021` or `telnet... (full message at <https://catircservices.org/_irc/v1/media/download/AcHnAtOM3eNoBA68H9rkh4SZDwCg2WKRU4DhH5dj6rdMNgN8htrr9Leoeh4G7BG9kuVBFWNvoaOQn7NLk1IvQ4q_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy90RFJodmZjaVdnY01YZHNmZE5FZWFpZEk>)

08:26 <RobinMueller[m]> i have to connect once with the JLinkRTTViewer, and then it works when I connect with other tools

08:29 <M9names[m]> the socket interface will accept configuration settings if you pipe them into it in the first few milliseconds.

08:29 <M9names[m]> i wrote a client that does this, maybe this will work for you? you might have to adjust the channel number if you're using a different up-channel.

08:29 <M9names[m]> https://github.com/9names/jlink-rtt-client/blob/fcc848a187e3e4eaa1b476bdaf29f9b504036cdc/src/main.rs#L11

08:31 <RobinMueller[m]> ahh maybe it has to do something with not having specified the RTT ctrl block base address? Your solution might work for me and I can probably easily extend it to print defmt frames as well.

08:53 <RobinMueller[m]> hmm, a SEGGER tools update seems to solve this as well

09:11 <JamesMunns[m]> oooh, rad hardened stuff?

09:11 <RobinMueller[m]> hmm.. I guess the only cavaet is that the full path to the binary has to be specified. integrated tools like probe-rs really are nice, but the debugging is still problematic unfortunately, so I still need to use JLink GDB Server + GDB mulitarch for debugging

09:11 <RobinMueller[m]> but defmt works now, amazing

09:12 <RobinMueller[m]> yeah. it is also too expensive. they don't even have a cheap development version 😅

09:12 <JamesMunns[m]> Very cool :D

09:17 <RobinMueller[m]> i am looking forward too developing firmware for these things with probe-rs / defmt etc. It was tons of work to add Rust support for those 😅 but it is so much better than the C libs / ecosystem provided by the vendor

09:18 <RobinMueller[m]> s/firmware/OBSW/

09:21 <JamesMunns[m]> I totally get how you get the name in German, but it is somewhat funny to me that y'all ended up with "US-IRS" :D

09:42 <phcoder_cat[m]> <dngrs[m]> "your error is cut off at "..." <- Here is the piece of code and the full error: https://pastebin.com/vZwHdfgn

10:21 <ian_rees[m]> thejpster: As far as I can tell, the clock is running the same* speed, and the compilation of `delay()` is the same, yet the firmware definitely goes a lot slower. This strange behaviour was noticed in the context of a rework of the ATSAMD HAL clocking, so initially I suspected that the clock tree was being misconfigured but AFAICT it's all fine and I can't imagine a mechanism that would make eg the `usb` feature affect the clock

10:21 <ian_rees[m]> tree setup. * One odd symptom I can't explain is that the clock is a bit unstable/jittery when the micro is running in the slow condition

10:21 <ian_rees[m]> * thejpster: As far as I can tell, the clock is running the same\* speed, and the compilation of `delay()` is the same, yet the debug output definitely goes a lot slower. This strange behaviour was noticed in the context of a rework of the ATSAMD HAL clocking, so initially I suspected that the clock tree was being misconfigured but AFAICT it's all fine and I can't imagine a mechanism that would make eg the `usb` feature affect the

10:21 <ian_rees[m]> clock tree setup. \* One odd symptom I can't explain is that the clock is a bit unstable/jittery when the micro is running in the slow condition

10:24 <ian_rees[m]> It's really puzzling, my leading theory is that there's some miscompilation/uninitialized variable that somehow puts the chip in to a bad state but it's very handwavy

10:31 <ian_rees[m]> The clock setup has a 48MHz open-loop PLL (the default that the chip starts up with), divided down to 2MHz, then multiplied by 50x to be 100MHz. The slowdown depending on enabled features is like 3.3x or 4.7x, and the set of enabled features that changes it between slow and fast conditions changes depending on what seem like inconsequential changes to the rest of the program. Maybe something relating to how the firmware

10:31 <ian_rees[m]> initializes RAM?

10:33 <ian_rees[m]> * or 4.7x (has varied when I've measured it,, * , not obviously related to the PLL ratios), and the

10:48 <thejpster[m]> Try turning interrupts off.

11:00 <ian_rees[m]> no change, using cortex_m::interrupt::disable(); as the first line in main()

11:01 <ian_rees[m]> another thing I've noticed is that the jittery clock symptom goes away when I break execution in a debugger, returns when the target resumes execution

11:07 <ian_rees[m]> It's past bedtime here so GTG, but I'm thinking to try producing "fast" and "slow" firmwares that differ in some smaller way than enabling HAL features - I'm pretty sure that all that is changing is the RAM initialization but could be something else there. Also we've only investigated on one board so will see if I have a different one that uses the same micro

14:50 <GrantM11235[m]> <thejpster[m]> "is it the clock speed that’s..." <- btw, `asm::delay` is already written in assembly

18:51 <thejpster[m]> Oh cool. I’m old enough to remember when we needed feature gates on nightly to use inline assembly.

18:52 <thejpster[m]> <RobinMueller[m]> "```sh..." <- > <@muellerr:matrix.org> ```sh... (full message at <https://catircservices.org/_irc/v1/media/download/AWUCkqQx0RUNu76K1rdHMErkz3SFersQXjY6c5GBcTt8diJuZhPStNXQ6UHqdhJ8JnE3wlT0knxc10_OQK9eJia_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9kQlFGYVNIU2NCeW1aYXhudE1qQ3FodGo>)

18:53 <thejpster[m]> The socket is open regardless of which segger tool you use. At embedded world I was using defmt-print whilst debugging in Ozone (which is great, btw)