Hardfault when starting STM32F030, __libc_init_array

Question

I am trying to get a STM32Cube project compiled using arm-none-eabi-gcc and Makefile. I pointed:

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 

FW builds without a problem. But when I load the MCU, I get stuck in Hard Fault. Stack trace:

 #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 switching 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 entry point.*/ bl main 

Any ideas what could be wrong?

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

[edit] Call parsing

 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] 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

This __libc_init_array is an ARM code, not a Thumb, therefore, M0 will fall over trying to do some kind of stupidity that he does not understand (in fact, he never gets there since he is mistaken when trying to switch to ARM state in bx , but hey, the same difference ...)

You need to make sure that you are using pure-Thumb versions for any libraries. A Cortex-M target link may be better than a generic ARM code. If you have a multilib toolkit, I would suggest checking out the output of arm-none-eabi-gcc --print-multi-lib to make sure you specify all the relevant options to get the correct Cortex-M libraries, and if you use a separate link step, make sure you invoke it using LD=arm-none-eabi-gcc (plus the corresponding multilib options), and not LD=arm-none-eabi-ld .