ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
unknown__ has quit [Ping timeout: 252 seconds]
creich has joined #rust-embedded
lowq has quit [Remote host closed the connection]
explore has quit [Quit: Connection closed for inactivity]
hwj has joined #rust-embedded
hwj has quit [Ping timeout: 260 seconds]
jackneilll has quit [Quit: Leaving]
explore has joined #rust-embedded
emerent has quit [Ping timeout: 252 seconds]
emerent_ has joined #rust-embedded
emerent_ is now known as emerent
tafa has quit [Quit: ZNC -]
tafa has joined #rust-embedded
<re_irc> <Chris [pwnOrbitals]> Hey guys, you may have some insight on this so I'd be glad if somebody could take a look :
<re_irc> thanks <3
explore has quit [Quit: Connection closed for inactivity]
Shell has quit [Quit: ZNC 1.8.2 -]
explore has joined #rust-embedded
Shell has joined #rust-embedded
<re_irc> <Udayakumar Hidakal> Hello,
<re_irc> But i am unable to debug the things regarding flash writing/erasing,
<re_irc> please help me if any one is working on this board.
<re_irc> I am working on "TM4C123GXL" development board,
<re_irc> <9names (> look at the setup for monotron for an example on how to use openocd with tm4c123gxl
hwj has joined #rust-embedded
<re_irc> <adamgreig> Chris [pwnOrbitals]: this is a great resource on debugging hardfault that might help you narrow down the exact cause:
<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
<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)
<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)
<re_irc> <Chris [pwnOrbitals]> MMARVALID is not set so the MMFAR has 0x00 so I don't know the exact address at fault
<re_irc> <Chris [pwnOrbitals]> best I can do is single-stepping and seeing when it faults (what I did in the issue report)
<re_irc> <Chris [pwnOrbitals]> but I don't have much information to work with
<re_irc> <Chris [pwnOrbitals]> ( adamgreig )
<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>")
<re_irc> <adamgreig> could it be that it made the jump and then faulted on an instruction in the __aeabi_memclr4 function?
<re_irc> <adamgreig> do you have the PC that triggered the fault?
<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
<re_irc> <adamgreig> can you read the pc from the ExceptionFrame you get in the hardfault handler?
<re_irc> <Chris [pwnOrbitals]> I haven't implemented a hardfault handler myself, could do that yes
<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/"
<re_irc> <adamgreig> it faulted on a branch to code in flash?
<re_irc> <adamgreig> what instruction's at 80015c4?
<re_irc> <Chris [pwnOrbitals]> (gdb) x/32i 0x080015c4
<re_irc> 0x80015c6 <compiler_builtins::mem::memcmp>: push {r4, r5, r6, r7, lr}
<re_irc> 0x80015c4 <compiler_builtins::mem::memset+154>: pop {r4, r6, r7, pc}
<re_irc> <Chris [pwnOrbitals]> adamgreig: yes
<re_irc> <adamgreig> what's your stack pointer, could you be running out of stack?
<re_irc> <adamgreig> (also in the ExceptionFrame)
<re_irc> <adamgreig> hmm seems unlikely as usually that would just start writing to .data/.bss unless you're using flip-link
<re_irc> <adamgreig> weird place for it to fault :/
<re_irc> <Chris [pwnOrbitals]> (gdb) x/w $msp
<re_irc> 0x1fffc1c0: 0xffffffff
<re_irc> <Chris [pwnOrbitals]> I'm not using flip-link (I don't even know what this is). Indeed it's weird !
<re_irc> <Chris [pwnOrbitals]> ah just discovered flip-link ! nice. Not using it
<re_irc> <adamgreig> hmmm, $msp is 0x1fffc1c0?
<re_irc> <Chris [pwnOrbitals]> correct
<re_irc> <adamgreig> presumably your RAM starts at 0x2000_0000 and 0x1FFFC1C0 is dead space?
<re_irc> <adamgreig> pretty huge stack overflow though, are you allocating like 16kB on the stack?
<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
<re_irc> <ithinuel> If you build in debug mode, rust's quite stack hungry.
<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
<re_irc> <adamgreig> suggests one huge allocation and the fault is on the next thing to touch sp
<re_irc> <adamgreig> (which is that "pop" at 800015c4)
<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
<re_irc> <adamgreig> how much ram do you have though? on an f7 presumably a reasonable bit?
<re_irc> <Chris [pwnOrbitals]> * burst-reading
<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?
<re_irc> <Chris [pwnOrbitals]> yeah 1M
<re_irc> <adamgreig> like, returning 1kb from a function call that doesn't get inlined can often go poorly
<re_irc> <adamgreig> (no guaranteed NRVO)
<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?)
<re_irc> <Chris [pwnOrbitals]> start is at 0x20000000, and max size in my linker script is 64 + 240 + 16 = 320kB
<re_irc> <chrysn (> adamgreig: Not guaranteed, but does an on-stack return actually ever happen? (I mean, the compiler _knows_ all the sizes...)
<re_irc> <Chris [pwnOrbitals]> I didn't customize it with my current target, took a default one tbh, I could give it more space
<re_irc> <chrysn (> (Sorry, this is probably distracting from the problem at hand, nvm)
<re_irc> <Chris [pwnOrbitals]> chrysn: (we're on a right track to solving it, I've had some great help already so dw ! )
<re_irc> <adamgreig> so you have 320kB of stack and are somehow overflowing by 15kB
<re_irc> <adamgreig> RAM LENGTH is 320kB in memory.x?
<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
<re_irc> <adamgreig> or at least, the majority of people coming here with stack overflows had some huge stack-returned object responsible
<re_irc> <adamgreig> (where one copy would have been fine, but they were getting like three+ copies and it wasn't fine)
<re_irc> <Chris [pwnOrbitals]> ("_stack_start = ORIGIN(RAM) + LENGTH(RAM);")
<re_irc> <Chris [pwnOrbitals]> adamgreig: yes
<re_irc> <adamgreig> wow, so something is really hammering the stack huh
explore has quit [Quit: Connection closed for inactivity]
<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 ?
<re_irc> <adamgreig> not sure, sorry
<re_irc> <adamgreig> armv8 has the amazing STKLIM register
<re_irc> <Chris [pwnOrbitals]> It's fine. I'll debug that on my end and keep you posted if I find something weird
<re_irc> <Chris [pwnOrbitals]> thanks a lot for the help :)
<re_irc> <adamgreig> np! I guess just keep stepping and printing sp until it suddenly goes wild
<re_irc> <adamgreig> good luck
<re_irc> <Chris [pwnOrbitals]> yep x) thank you
<re_irc> <chrysn (> This all reminds me to resume hacking on cargo-call-stack, which might have been helpful here.
<re_irc> <Chris [pwnOrbitals]> okay I found
<re_irc> <Chris [pwnOrbitals]> the weird thing is that even very early on my stack pointer was overflowing
<re_irc> <Chris [pwnOrbitals]> which came from in the error in my _stack_start pointer
<re_irc> <Chris [pwnOrbitals]> that was actually pointing 320 bytes in, and not 320K bytes
<re_irc> <Chris [pwnOrbitals]> what a dumb mistake
<re_irc> <adamgreig> aha, well, that will do it
<re_irc> <adamgreig> are you manually setting _stack_start?
<re_irc> <adamgreig> or was it just the LENGTH on RAM set to 320 instead of 320K?
<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
<re_irc> <adamgreig> ah ok
<re_irc> <Chris [pwnOrbitals]> yeah the length was bad
<re_irc> <Chris [pwnOrbitals]> but the length is set programmatically
<re_irc> <Chris [pwnOrbitals]> depending on the position of the program
<re_irc> <Chris [pwnOrbitals]> adamgreig: it was actually set to 0x320 (lol), must have been tired when writing
<re_irc> <Chris [pwnOrbitals]> * "0x320" instead of "320K"
hwj has quit [Remote host closed the connection]
hwj2 has joined #rust-embedded
hwj2 has quit [Remote host closed the connection]
hwj2 has joined #rust-embedded
hwj2 has quit [Remote host closed the connection]
hwj has joined #rust-embedded
explore has joined #rust-embedded
hwj has quit [Ping timeout: 272 seconds]
<re_irc> <jamwaffles> Has there been any progress on running "cargo bench" either on-device or in QEMU?
<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
<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
<re_irc> <adamgreig> jamwaffles: on cortex-m3/m4/m7 you can use and
<re_irc> <adamgreig> just grab the number of cycles at start/end of your routine
<re_irc> <adamgreig> (and call first too)
<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?
<re_irc> <adamgreig> it counts CPU clock cycles, so HCLK (sysclk) on an stm32f1
<re_irc> <jamwaffles> Good to know, ty
<re_irc> <newam> This is what I use for the STM32WL tests:
<re_irc> #[inline(always)]
<re_irc> fn stopwatch<F>(f: F) -> u32
<re_irc> where
explore has quit [Quit: Connection closed for inactivity]
dreamcat4 has joined #rust-embedded
hwj has joined #rust-embedded
hwj has quit [Client Quit]
bjc has quit [Remote host closed the connection]
bjc has joined #rust-embedded
Foxyloxy has quit [Ping timeout: 250 seconds]
Foxyloxy has joined #rust-embedded