09:22 <re_irc> <Chris [pwnOrbitals]> Hey guys, you may have some insight on this so I'd be glad if somebody could take a look : https://github.com/fizyk20/generic-array/issues/121

09:22 <re_irc> thanks <3

10:03 <re_irc> <Udayakumar Hidakal> Hello,

10:03 <re_irc> But i am unable to debug the things regarding flash writing/erasing,

10:03 <re_irc> please help me if any one is working on this board.

10:03 <re_irc> I am working on "TM4C123GXL" development board,

10:29 <re_irc> <9names (@9names:matrix.org)> look at the setup for monotron https://github.com/thejpster/monotron for an example on how to use openocd with tm4c123gxl

11:05 <re_irc> <adamgreig> Chris [pwnOrbitals]: this is a great resource on debugging hardfault that might help you narrow down the exact cause: https://interrupt.memfault.com/blog/cortex-m-fault-debug

11:05 <re_irc> <adamgreig> on stm32f7 you're allowed to do unaligned access (it's just slow) iirc, so i don't think that is likely the cause

11:06 <re_irc> <adamgreig> (some instructions can't do unaligned access though, maybe it's faulting on one of them like strd? hard to tell from the backtrace)

11:11 <re_irc> <Chris [pwnOrbitals]> yeah, I'm using this, but it's weird. the CFSR indicates a MemManage IACCVIOL but the jumps on the code path look fine (the sections are not nx)

11:11 <re_irc> <Chris [pwnOrbitals]> MMARVALID is not set so the MMFAR has 0x00 so I don't know the exact address at fault

11:12 <re_irc> <Chris [pwnOrbitals]> best I can do is single-stepping and seeing when it faults (what I did in the issue report)

11:12 <re_irc> <Chris [pwnOrbitals]> but I don't have much information to work with

11:12 <re_irc> <Chris [pwnOrbitals]> ( adamgreig )

11:14 <re_irc> <Chris [pwnOrbitals]> Maybe there's a condition that I don't know of that triggers a MemFault at jump (the faulty instruction is probably " 0x08000274 <+24>: bl 0x800175e <compiler_builtins::arm::__aeabi_memclr4>")

11:15 <re_irc> <adamgreig> could it be that it made the jump and then faulted on an instruction in the __aeabi_memclr4 function?

11:15 <re_irc> <adamgreig> do you have the PC that triggered the fault?

11:17 <re_irc> <Chris [pwnOrbitals]> ah, could be. I'll try to find it, but as I said earlier the faulty address isn't in the MMFAR so I need to find it by hand. I'll ping you when I find it

11:23 <re_irc> <adamgreig> can you read the pc from the ExceptionFrame you get in the hardfault handler?

11:24 <re_irc> <Chris [pwnOrbitals]> I haven't implemented a hardfault handler myself, could do that yes

11:29 <re_irc> <Chris [pwnOrbitals]> anyway, got it the hard way with gdb. culprit is "0x80015a2 <compiler_builtins::mem::memset+120>: blt.n 0x80015c4 <compiler_builtins::mem::memset+154>", next executed instruction is the HardFaultTrampoline. Corresponding source is "compiler_builtins::mem::memset () at /cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.67/src/mem/mod.rs:48"

11:38 <re_irc> <adamgreig> it faulted on a branch to code in flash?

11:38 <re_irc> <adamgreig> what instruction's at 80015c4?

11:51 <re_irc> <Chris [pwnOrbitals]> (gdb) x/32i 0x080015c4

11:51 <re_irc> 0x80015c6 <compiler_builtins::mem::memcmp>: push {r4, r5, r6, r7, lr}

11:51 <re_irc> 0x80015c4 <compiler_builtins::mem::memset+154>: pop {r4, r6, r7, pc}

11:52 <re_irc> <Chris [pwnOrbitals]> adamgreig: yes

11:53 <re_irc> <adamgreig> what's your stack pointer, could you be running out of stack?

11:54 <re_irc> <adamgreig> (also in the ExceptionFrame)

11:54 <re_irc> <adamgreig> hmm seems unlikely as usually that would just start writing to .data/.bss unless you're using flip-link

11:54 <re_irc> <adamgreig> weird place for it to fault :/

11:55 <re_irc> <Chris [pwnOrbitals]> (gdb) x/w $msp

11:55 <re_irc> 0x1fffc1c0: 0xffffffff

11:56 <re_irc> <Chris [pwnOrbitals]> I'm not using flip-link (I don't even know what this is). Indeed it's weird !

11:57 <re_irc> <Chris [pwnOrbitals]> ah just discovered flip-link ! nice. Not using it

11:59 <re_irc> <adamgreig> hmmm, $msp is 0x1fffc1c0?

12:00 <re_irc> <Chris [pwnOrbitals]> correct

12:00 <re_irc> <adamgreig> presumably your RAM starts at 0x2000_0000 and 0x1FFFC1C0 is dead space?

12:02 <re_irc> <adamgreig> pretty huge stack overflow though, are you allocating like 16kB on the stack?

12:02 <re_irc> <Chris [pwnOrbitals]> correct. I'm looking at the docs now. 0x1FFFC1C0 is some reserved space, pretty sure any read or write there would fault

12:03 <re_irc> <ithinuel> If you build in debug mode, rust's quite stack hungry.

12:03 <re_irc> <adamgreig> i'd have thought it would fault earlier if it's just generally large stack usage, this is already like 15kB below the bottom of the stack

12:03 <re_irc> <adamgreig> suggests one huge allocation and the fault is on the next thing to touch sp

12:04 <re_irc> <adamgreig> (which is that "pop" at 800015c4)

12:05 <re_irc> <Chris [pwnOrbitals]> at max my code is reading 1kB of flash to the stack (quite a lot already). Might come from the sha2 crate I'm using

12:06 <re_irc> <adamgreig> how much ram do you have though? on an f7 presumably a reasonable bit?

12:06 <re_irc> <Chris [pwnOrbitals]> * burst-reading

12:06 <re_irc> <adamgreig> or could you be burst reading 1kB but in such a way that you end up with a lot of 1kB stack allocations live at the same time?

12:06 <re_irc> <Chris [pwnOrbitals]> yeah 1M

12:06 <re_irc> <adamgreig> like, returning 1kb from a function call that doesn't get inlined can often go poorly

12:07 <re_irc> <adamgreig> (no guaranteed NRVO)

12:07 <re_irc> <adamgreig> jeez. so where does your stack pointer start? (what's _stack_start in memory.x / what's the start and length of the "RAM" section?)

12:09 <re_irc> <Chris [pwnOrbitals]> start is at 0x20000000, and max size in my linker script is 64 + 240 + 16 = 320kB

12:10 <re_irc> <chrysn (@chrysn:matrix.org)> adamgreig: Not guaranteed, but does an on-stack return actually ever happen? (I mean, the compiler _knows_ all the sizes...)

12:10 <re_irc> <Chris [pwnOrbitals]> I didn't customize it with my current target, took a default one tbh, I could give it more space

12:10 <re_irc> <chrysn (@chrysn:matrix.org)> (Sorry, this is probably distracting from the problem at hand, nvm)

12:11 <re_irc> <Chris [pwnOrbitals]> chrysn: (we're on a right track to solving it, I've had some great help already so dw ! )

12:12 <re_irc> <adamgreig> so you have 320kB of stack and are somehow overflowing by 15kB

12:12 <re_irc> <adamgreig> RAM LENGTH is 320kB in memory.x?

12:13 <re_irc> <adamgreig> chrysn: there's been a bunch of recent work on improving NVRO but I think there are still situations where it happens on stack, yea

12:13 <re_irc> <adamgreig> or at least, the majority of people coming here with stack overflows had some huge stack-returned object responsible

12:13 <re_irc> <adamgreig> (where one copy would have been fine, but they were getting like three+ copies and it wasn't fine)

12:13 <re_irc> <Chris [pwnOrbitals]> ("_stack_start = ORIGIN(RAM) + LENGTH(RAM);")

12:14 <re_irc> <Chris [pwnOrbitals]> adamgreig: yes

12:14 <re_irc> <adamgreig> wow, so something is really hammering the stack huh

12:15 <re_irc> <Chris [pwnOrbitals]> it looks like. I'm checking it out rn, do you know if I can get gdb to break when the stack get pushed by more than a given amount ?

12:16 <re_irc> <adamgreig> not sure, sorry

12:16 <re_irc> <adamgreig> armv8 has the amazing STKLIM register

12:17 <re_irc> <Chris [pwnOrbitals]> It's fine. I'll debug that on my end and keep you posted if I find something weird

12:17 <re_irc> <Chris [pwnOrbitals]> thanks a lot for the help :)

12:17 <re_irc> <adamgreig> np! I guess just keep stepping and printing sp until it suddenly goes wild

12:17 <re_irc> <adamgreig> good luck

12:18 <re_irc> <Chris [pwnOrbitals]> yep x) thank you

12:18 <re_irc> <chrysn (@chrysn:matrix.org)> This all reminds me to resume hacking on cargo-call-stack, which might have been helpful here.

12:37 <re_irc> <Chris [pwnOrbitals]> okay I found

12:37 <re_irc> <Chris [pwnOrbitals]> the weird thing is that even very early on my stack pointer was overflowing

12:38 <re_irc> <Chris [pwnOrbitals]> which came from in the error in my _stack_start pointer

12:38 <re_irc> <Chris [pwnOrbitals]> that was actually pointing 320 bytes in, and not 320K bytes

12:38 <re_irc> <Chris [pwnOrbitals]> what a dumb mistake

12:39 <re_irc> <adamgreig> aha, well, that will do it

12:39 <re_irc> <adamgreig> are you manually setting _stack_start?

12:39 <re_irc> <adamgreig> or was it just the LENGTH on RAM set to 320 instead of 320K?

12:39 <re_irc> <Chris [pwnOrbitals]> yup, it's a system with multiple copies of the same program, so the linker script is generated on-the-fly in build.rs

12:39 <re_irc> <adamgreig> ah ok

12:39 <re_irc> <Chris [pwnOrbitals]> yeah the length was bad

12:40 <re_irc> <Chris [pwnOrbitals]> but the length is set programmatically

12:40 <re_irc> <Chris [pwnOrbitals]> depending on the position of the program

12:42 <re_irc> <Chris [pwnOrbitals]> adamgreig: it was actually set to 0x320 (lol), must have been tired when writing build.rs

12:43 <re_irc> <Chris [pwnOrbitals]> * "0x320" instead of "320K"

14:53 <re_irc> <jamwaffles> Has there been any progress on running "cargo bench" either on-device or in QEMU?

14:53 <re_irc> <jamwaffles> Failing that, if anyone has some generic code for RTIC which can time how long an operation takes (i.e. an FPS counter or similar) and is willing to share, that would be enough

14:53 <re_irc> <jamwaffles> I want to optimise some of my display drivers but benchmarking on x64 for stuff that runs on thumbv6m is obviously pretty silly

16:26 <re_irc> <adamgreig> jamwaffles: on cortex-m3/m4/m7 you can use https://docs.rs/cortex-m/latest/cortex_m/peripheral/struct.DWT.html#method.enable_cycle_counter and https://docs.rs/cortex-m/latest/cortex_m/peripheral/struct.DWT.html#method.cycle_count

16:26 <re_irc> <adamgreig> just grab the number of cycles at start/end of your routine

16:27 <re_irc> <adamgreig> (and call https://docs.rs/cortex-m/latest/cortex_m/peripheral/struct.DCB.html#method.enable_trace first too)

17:04 <re_irc> <jamwaffles> Thanks! I'll check those links out. If I add it to my e.g. stm32f1xx-hal project, which clock rate does it run at?

17:13 <re_irc> <adamgreig> it counts CPU clock cycles, so HCLK (sysclk) on an stm32f1

17:23 <re_irc> <jamwaffles> Good to know, ty

17:24 <re_irc> <newam> This is what I use for the STM32WL tests: https://github.com/stm32-rs/stm32wlxx-hal/blob/main/testsuite/src/aes.rs#L1485

17:24 <re_irc> #[inline(always)]

17:24 <re_irc> fn stopwatch<F>(f: F) -> u32

17:24 <re_irc> where

17:24 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/4239dace3c3e62439667cf2440851d8a7bca4446deb21de676d7b2ba749cc95c (11 lines)