2014-10-27 91 views
7

我想獲得一個使用arm-none-eabi-gcc和Makefile編譯的STM32Cube項目。 我指定:在STM32F030啓動時的硬故障,__libc_init_array

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

和:

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

的FW建立無問題。但是,當我啓動單片機的I陷入硬故障。 堆棧跟蹤:

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

,我直奔硬故障在啓動文件步進到bl __libc_init_array時。

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

任何想法什麼可能是錯的?

我的臂-NONE-EABI-gcc版本是4.8.4 20140725(釋放)

[編輯] 呼叫

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 

[編輯2] 寄存器值從所述的拆卸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 
+0

反彙編文件,查看跳轉的位置,然後檢查該地址的代碼。也許你正在鏈接的libc有一些問題,這會導致跳轉或其他問題。 – unwind 2014-10-27 10:41:40

+0

@unwind它可能是它使用'b'指令進行分支,但跳轉超過+/- 2kB? – evading 2014-10-27 11:02:30

回答

8

__libc_init_array是ARM代碼,而不是拇指,因此M0會摔倒試圖執行一些廢話不理解(一事實上,它從來沒有完全到達那裏,因爲它嘗試在bx中嘗試切換到ARM狀態,但是,同樣的區別......)

您需要確保使用純拇指版本的任何庫 - 與通用ARM相比,Cortex-M專用工具鏈可能更好。如果你有一個multilib工具鏈,我建議檢查arm-none-eabi-gcc --print-multi-lib的輸出以確保你已經指定了所有相關的選項來獲得適當的Cortex-M庫,並且如果你使用單獨的鏈接步驟,請確保你調用它與LD=arm-none-eabi-gcc(加上相關multilib選項),而不是LD=arm-none-eabi-ld

+5

我錯過了給-mcpu = cortex-m0和-mthumb作爲鏈接時間標誌。 – evading 2014-10-28 06:43:27

+0

很好的答案。對於碰到這種情況的人來說,可能還有其他原因:如果你自己構建了工具鏈,你應該啓用multilib,並確保你的t-arm-elf支持所有的Cortex-M(也可能是arm7tdmi-s) 。 – 2015-04-30 00:15:16