Hardfault on STM32F030 startup, __libc_init_array

Question

I'm trying to get a STM32Cube project compiled using arm-none-eabi-gcc and a Makefile. I have specified:

CFLAGS = -mthumb\
         -march=armv6-m\
         -mlittle-endian\
         -mcpu=cortex-m0\
         -ffunction-sections\
         -fdata-sections\
         -MMD\
         -std=c99\
         -Wall\
         -g\
         -D$(PART)\
         -c

and:

LDFLAGS = -Wl,--gc-sections\
          -Wl,-T$(LDFILE)\
          -Wl,-v

The FW builds without problems.but when I boot the MCU i get stuck in Hard Fault. Stack trace is:

#0  HardFault_Handler () at ./Src/main.c:156
#1  <signal handler called>
#2  0x0800221c in ____libc_init_array_from_thumb ()
#3  0x080021be in LoopFillZerobss () at Src/startup_stm32f030x8.s:103
#4  0x080021be in LoopFillZerobss () at Src/startup_stm32f030x8.s:103
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

and I go straight to Hard Fault when stepping to bl __libc_init_array in the startup file.

/* Zero fill the bss segment. */
FillZerobss:
  movs r3, #0
  str  r3, [r2]
  adds r2, r2, #4


LoopFillZerobss:
  ldr r3, = _ebss
  cmp r2, r3
  bcc FillZerobss

/* Call the clock system intitialization function.*/
  bl  SystemInit
/* Call static constructors */
  bl __libc_init_array
/* Call the application's entry point.*/
  bl main

Any ideas what could be wrong?

My arm-none-eabi-gcc version is 4.8.4 20140725 (release)

[edit] The disassembly of the calls

08002218 <____libc_init_array_from_thumb>:
8002218:   4778        bx  pc
800221a:   46c0        nop         ; (mov r8, r8)
800221c:   eafff812    b   800026c <__libc_init_array>

0800026c <__libc_init_array>:
800026c:   e92d4070    push    {r4, r5, r6, lr}
8000270:   e59f506c    ldr r5, [pc, #108]  ; 80002e4 <__libc_init_array+0x78>
8000274:   e59f606c    ldr r6, [pc, #108]  ; 80002e8 <__libc_init_array+0x7c>
8000278:   e0656006    rsb r6, r5, r6
800027c:   e1b06146    asrs    r6, r6, #2
8000280:   12455004    subne   r5, r5, #4
8000284:   13a04000    movne   r4, #0
8000288:   0a000005    beq 80002a4 <__libc_init_array+0x38>
800028c:   e2844001    add r4, r4, #1
8000290:   e5b53004    ldr r3, [r5, #4]!
8000294:   e1a0e00f    mov lr, pc
8000298:   e12fff13    bx  r3
800029c:   e1560004    cmp r6, r4
80002a0:   1afffff9    bne 800028c <__libc_init_array+0x20>
80002a4:   e59f5040    ldr r5, [pc, #64]   ; 80002ec <__libc_init_array+0x80>
80002a8:   e59f6040    ldr r6, [pc, #64]   ; 80002f0 <__libc_init_array+0x84>
80002ac:   e0656006    rsb r6, r5, r6
80002b0:   eb0007ca    bl  80021e0 <_init>
80002b4:   e1b06146    asrs    r6, r6, #2
80002b8:   12455004    subne   r5, r5, #4
80002bc:   13a04000    movne   r4, #0
80002c0:   0a000005    beq 80002dc <__libc_init_array+0x70>
80002c4:   e2844001    add r4, r4, #1
80002c8:   e5b53004    ldr r3, [r5, #4]!
80002cc:   e1a0e00f    mov lr, pc
80002d0:   e12fff13    bx  r3
80002d4:   e1560004    cmp r6, r4
80002d8:   1afffff9    bne 80002c4 <__libc_init_array+0x58>
80002dc:   e8bd4070    pop {r4, r5, r6, lr}
80002e0:   e12fff1e    bx  lr
80002e4:   08002258    .word   0x08002258
80002e8:   08002258    .word   0x08002258
80002ec:   08002258    .word   0x08002258
80002f0:   08002260    .word   0x08002260

[edit 2] The register values from gdb:

(gdb) info reg
r0             0x20000000   536870912
r1             0x1  1
r2             0x0  0
r3             0x40021000   1073876992
r4             0xffffffff   -1
r5             0xffffffff   -1
r6             0xffffffff   -1
r7             0x20001fd0   536879056
r8             0xffffffff   -1
r9             0xffffffff   -1
r10            0xffffffff   -1
r11            0xffffffff   -1
r12            0xffffffff   -1
sp             0x20001fd0   0x20001fd0
lr             0xfffffff9   -7
pc             0x800067c    0x800067c <HardFault_Handler+4>
xPSR           0x61000003   1627389955

Answer 1

That __libc_init_array is ARM code, not Thumb, hence the M0 will fall over trying to execute some nonsense it doesn't understand (actually, it never quite gets there since it faults on the attempt to switch to ARM state in the bx, but hey, same difference...)

You'll need to make sure you use pure-Thumb versions of any libraries - a Cortex-M-specific toolchain might be a better bet than a generic ARM one. If you have a multilib toolchain, I'd suggest checking the output of arm-none-eabi-gcc --print-multi-lib to make sure you've specified all the relevant options to get proper Cortex-M libraries, and if you're using a separate link step, make sure you invoke it with LD=arm-none-eabi-gcc (plus the relevant multilib options), rather than LD=arm-none-eabi-ld.