Cortex m3第一条指令执行

时间:2013-03-19 22:20:35

标签: c assembly initialization startup cortex-m3

我正在使用Sourcery CodeBench Lite 2012.03-56编译器和带有texane gdb server的gdb套件。

今天我想试试廉价的STM32VLDISCOVERY板的FreeRTOS演示示例,我复制了所有需要的源文件,编译时没有错误但是示例没有用。我启动了调试器并注意到该示例在尝试取消引用指向GPIO寄存器的指针时失败。全局数组变量,包含指向GPIO寄存器的指针:

GPIO_TypeDef* GPIO_PORT[LEDn] = {LED3_GPIO_PORT, LED4_GPIO_PORT};

未正确初始化并且填充了一些随机值。我检查了预处理器定义的LED3_GPIO_PORT和LED3_GPIO_PORT,它们是有效的。

经过一些研究可能出现问题的地方后,我查看了为CMSIS lib中的trueSTUDIO提供的启动文件。原始startup_stm32f10x_md_vl.S文件:

    .section    .text.Reset_Handler
    .weak   Reset_Handler
    .type   Reset_Handler, %function
Reset_Handler:

/* Copy the data segment initializers from flash to SRAM */
  movs  r1, #0
  b LoopCopyDataInit

CopyDataInit:
    ldr r3, =_sidata
    ldr r3, [r3, r1]
    str r3, [r0, r1]
    adds    r1, r1, #4

LoopCopyDataInit:
    ldr r0, =_sdata
    ldr r3, =_edata
    adds    r2, r0, r1
    cmp r2, r3
    bcc CopyDataInit
    ldr r2, =_sbss
    b   LoopFillZerobss
...

在调试期间,我注意到寄存器r1从未通过第一条指令 movs r1,#0 初始化为零。寄存器r1用作循环中的计数器,因此当执行到达循环LoopCopyDataInit时,它永远不会进入循环,因为寄存器r1加载了来自先前执行的一些垃圾数据。由于此,启动代码永远不会初始化.data部分

当我在 movs r1,#0 指令之前放置两条nop指令时,寄存器r1被初始化为0并且示例开始工作:

startup_stm32f10x_md_vl.S文件的修改部分:

/* Copy the data segment initializers from flash to SRAM */
  nop
  nop
  movs  r1, #0
  b LoopCopyDataInit

这是最终代码相关部分的反汇编:

Disassembly of section .isr_vector:

08000000 <g_pfnVectors>:
 8000000:       20002000        andcs   r2, r0, r0
 8000004:       08000961        stmdaeq r0, {r0, r5, r6, r8, fp}
 ...

Disassembly of section .text:

 ...
8000960 <Reset_Handler>:
 8000960:   2100            movs    r1, #0
 8000962:   f000 b804       b.w     800096e <LoopCopyDataInit>

08000966 <CopyDataInit>:
 8000966:   4b0d            ldr     r3, [pc, #52]   ; (800099c <LoopFillZerobss+0x16>)
 8000968:   585b            ldr     r3, [r3, r1]
 800096a:   5043            str     r3, [r0, r1]
 800096c:   3104            adds    r1, #4 

如您所见,ISR向量表正确指向Reset_Handler地址。那么,发生了什么?为什么第一条指令 movs r1,#0 从未在原始启动代码中执行过?

修改

当我关闭电路板并重新打开电源时,原始代码可以正常工作。我可以多次重置MCU,它可以工作。当我启动gdb-server时,即使重置后代码也不起作用。我必须重新启动它再次工作。我想这是一些调试器的奇怪现象。

注意:

我看看其他人使用这个MCU的启动代码是什么,他们要么禁用中断,要么使用链接器定义的值加载SP寄存器,这在两种情况下都是冗余的。如果他们被这种奇怪的行为所打击,他们就不会注意到它。

2 个答案:

答案 0 :(得分:3)

听起来像是调试器中的错误。可能它会在第一条指令上设置一个断点,或者完全跳过它或以某种方式重新执行它不能正常工作。这个问题可能因为它是 reset 向量而变得复杂,也许它不可能在第一条指令处可靠地停止。由于NOP有帮助,我建议您在开发程序时将它们留在原位。

然而,还有另一种解决方案。由于您不太可能需要修改数组,因此在可写部分中并不需要它。要让编译器将数组放入flash中,通常只需将其声明为 const

GPIO_TypeDef* const GPIO_PORT[LEDn] = {LED3_GPIO_PORT, LED4_GPIO_PORT};

答案 1 :(得分:1)

没有什么可以立即跳出来,看那里可能出现的问题。首先,您如何调试此代码?您是否附加了调试器,然后通过JTAG向处理器发出复位?我会尝试将b Reset_Handler放在Reset_Handler:标签之后,作为第一条指令,将其打开,打开电路板,然后连接JTAG,以便最大限度地减少调试器的任何可能的怪异。然后将您的PC设置为mov指令,看看它是否有效。引导加载程序或引导ROM是否启动此代码?这可能是指令或数据缓存的奇怪现象。