Tahnks for your help, Matthias! On Thu, Oct 17, 2019 at 02:37:11PM +0200, Matthias Pfaller wrote: > Have a look at "arm-eabi-objdump -S -d main.elf". Sometimes this is > quite revealing. Yeah. > Are you using openocd or something similar for debugging? Yes. Openocd with gdb. > You are compiling for a cortex-m0/3/4? Cortex-m3 > Are you single stepping through the complete startup sequence or do set a > break point ath the top of memset (i.e. are break points working at all)? Breakpoints are working. But there is only a limited set of hardware breakpoints (four, AFAIR). > Interrupts are still disabled? There are no interrupt sources enabled yet. But I wonder why the CPU is not starting up with disabled IRQs? I am new to the ARM architecture, but every other architecture I know of would come out from reset with disabled interrupts... I'd expect BASEPRI and PRIMASK to be set to sane values before the first instruction is executed? Anyway, explicitly calling __set_PRIMASK(1) did also not help, although primask ist still set when the processor crashes. > Why is the stack pointer so low at this point of execution? Using > 0x20018000-0x20017d20 == 0x2e0 bytes of stack seems a little excessive > for just one call. Ah!... Looks like you've spotted the problem! Actually, the SP is decremented on every cycle of the loop: (gdb) disass Dump of assembler code for function memset: 0x08001008 <+0>: push {r4, lr} 0x0800100a <+2>: mov r4, r0 0x0800100c <+4>: cbz r2, 0x8001014 <memset+12> => 0x0800100e <+6>: uxtb r1, r1 0x08001010 <+8>: bl 0x8001008 <memset> 0x08001014 <+12>: mov r0, r4 0x08001016 <+14>: pop {r4, pc} End of assembler dump. This looks REALLY suspicous to me. Every cycle of the loop in memset() is pushing something onto the stack?!? Without the -ftree-loop-distribute-patterns option, the memset() function looks entirely different: cbz r2, <memset+18> add r2, r0 subs r2, #1 uxtb r1, r1 subs r3, r0, #1 <+10>: strb.w r1, [r3, #1]! cmp r3, r2 bne.n <memset+10> <+18>: bx lr > I usually start toggling output lines when I'm stuck like this... ? -- Josef Wolf jw@xxxxxxxxxxxxx