Arm 我应该如何初始化我的stm32（f215）

我正在尝试制作一个极其精简的stm32f215固件，让自己了解它的启动复杂性。现在我有了这个转储，据我所知，它应该将堆栈地址写入r0并永远循环：

firmware-d:     file format elf32-littlearm


Disassembly of section .isr_vector:

08000000 <vector>:
 8000000:       20002000        andcs   r2, r0, r0
 8000004:       08000009        stmdaeq r0, {r0, r3}

08000008 <reset_handler>:
 8000008:       f85f 00c       ldr.w   r0, [pc, #-12]  ; 8000000 <vector>

0800000c <loop>:
 800000c:       e7fe            b.n     800000c <loop>

（正如您可以看到的，0xc中的值当前是死代码。）

• 我几乎可以保证我使用的stlink应用程序将sp和lr混合在一起。已知良好的程序没有sp=0x8f0d180和lr=0x2001ff88。明天将研究使用openocd

---

罪犯已经找到了！ 看来st util调试器（来自上面提到的项目）以某种方式导致了错误。openocd的工作方式很有魅力，上面的代码非常简单
不管怎样，要写的bug报告和所有这些

---

非常感谢大家验证我的汇编程序，并帮助我完成所有的t点和i点
不熟悉这里的硬件，但我了解ARM。如果您的ISR正在登录，则它正在执行数据而不是代码。几乎100%确定这两个操作码是堆栈地址（0x20002000）和入口点（0x0800009）。注意地址是奇数，因此系统采用“拇指”指令。再次确认这是你想要的。我会在开机时使用手臂，所以这对我来说很奇怪。重新读取-引导到

0x800 0000

的别名几乎肯定意味着您正在执行“池”，而不是从重置处理程序开始。这也意味着您可能在执行第二条指令时抛出异常，因为R0几乎肯定是垃圾。要么将第一条指令作为您的分支，将您的启动管脚别名为，要么将您的池从入口点移开。“但是当我调试它时，我结束了…”-但是在那之前它做了什么？在

reset\u handler

上有一个断点，它甚至会停在那里吗？在任何情况下，将代码放在向量表中可能都不是一个好主意；如果出现NMI或硬故障异常，它会将代码解释为向量，并跳转到无效地址。您的

reset\u处理程序应该位于向量表上方。我更希望看到它在FLASH中，而不是在文件中。@P\uu J\uuuu：发布的代码是反汇编而不是源文件，因此它可能是FLASH中的内容。
(gdb) info registers 
r0             0x0                 0
r1             0x0                 0
r2             0x6d8d1d05          1837964549
r3             0x7fbf              32703
r4             0x8000008           134217736
r5             0x8000008           134217736
r6             0x8000008           134217736
r7             0x8000008           134217736
r8             0x8000008           134217736
r9             0x8000008           134217736
r10            0x8000008           134217736
r11            0x8000008           134217736
r12            0x8000008           134217736
sp             0x8000008           0x8000008
lr             0x8000008           134217736
pc             0x8000008           0x8000008
cpsr           0x8000008           134217736
(gdb) disassemble /r 0x0,0x10
Dump of assembler code from 0x0 to 0x10:
   0x00000000:  00 20   movs    r0, #0
   0x00000002:  00 20   movs    r0, #0
   0x00000004:  09 00   movs    r1, r1
   0x00000006:  00 08   lsrs    r0, r0, #32
   0x00000008:  00 48   ldr r0, [pc, #0]    ; (0xc)
   0x0000000a:  fe e7   b.n 0xa
   0x0000000c:  68 46   mov r0, sp

(gdb) disassemble /r 0x8000000,0x8000010
Dump of assembler code from 0x8000000 to 0x8000010:
   0x08000000 <vector+0>:   00 20   movs    r0, #0
   0x08000002 <vector+2>:   00 20   movs    r0, #0
   0x08000004 <vector+4>:   09 00   movs    r1, r1
   0x08000006 <vector+6>:   00 08   lsrs    r0, r0, #32
=> 0x08000008:  00 48   ldr r0, [pc, #0]    ; (0x800000c <reset_handler_c>)
   0x0800000a:  fe e7   b.n 0x800000a
   0x0800000c <reset_handler_c+0>:  68 46   mov r0, sp

(gdb) print/x *(uint32_t *) 0xE000ED28
$1 = 0x0
(gdb) print/x *(uint32_t *) 0xE000ED2C
$2 = 0x0