Errore hardware all'avvio di STM32F030, __libc_init_array

Question

Sto cercando di ottenere un progetto STM32Cube compilato utilizzando arm-none-eabi-gcc e un Makefile. Ho specificato:

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

e:

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

FW costruisce senza problems.but quando caric il MCU mi si blocca in Hard guasto. Stack traccia è:

#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?) 

e vado dritto al disco guasto quando si passa al bl __libc_init_array nel file di avvio.

/* 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 

Qualche idea cosa potrebbe essere sbagliato?

Il mio braccio-nessuno-EABI-gcc version 4.8.4 è 20.140.725 (rilascio)

[modifica] Lo smontaggio delle chiamate

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 

[modifica] 2 I valori di registro da 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

Questo __libc_init_array è il codice ARM, non Pollice, da qui il M0 cadrà sopra cercando di eseguire qualche sciocchezza che non capisce (una In realtà, non arriva mai abbastanza da quando commette errori nel tentativo di passare allo stato ARM nel bx, ma hey, stessa differenza ...)

Avrai bisogno di assicurarti di usare le versioni pure-Thumb di qualsiasi librerie - una toolchain specifica per Cortex-M potrebbe essere una scommessa migliore di una ARM generica. Se hai una toolchain multilib, ti suggerisco di controllare l'output di arm-none-eabi-gcc --print-multi-lib per assicurarti di aver specificato tutte le opzioni rilevanti per ottenere le librerie Cortex-M corrette e, se stai utilizzando un passaggio di collegamento separato, assicurati di invocare con LD=arm-none-eabi-gcc (più le relative opzioni multilib), anziché LD=arm-none-eabi-ld.