ARTICLE DETAIL

资讯详情

深耕商务建站与企业官网运营的一线实战洞察。

STM32F103纯汇编工程拆解:从启动文件到混合编程

STM32F103纯汇编工程拆解:从启动文件到混合编程 简介这份资源是一套基于STM32F103ARM Cortex-M3内核的汇编点灯例程工程面向已具备C语言基础、希望深入理解微控制器底层运行机制的嵌入式学习者与工程师。压缩包共19个文件、约28KB以Keil5工程文件uvprojx、uvoptx为核心配合汇编源文件与启动文件startup_stm32f10x_md.s、编译产物axf、o、lst、map、sct、JLink调试配置与日志以及keilkilll.bat清理脚本等构成可直接打开、编译、下载与在线调试的完整工程链路。程序围绕GPIO配置与寄存器操作展开涉及R0-R15通用寄存器与SP、LR、PC的使用LDR、STR、MOV、B等指令的加载存储与分支流程以及GPIOx_MODER、OTYPER、OSPEEDR、PUPDR等寄存器的直接写入可用于观察点灯与闪烁循环的指令级执行过程。已有1653人学习下载适合作为汇编入门的第一个可运行样例也可作为调试与寄存器验证的参考工程。1. 从一份纯汇编的 STM32F103 工程说起为什么还要碰汇编拿到一份纯汇编的 STM32F103 工程很多人的第一反应是这年头谁还写汇编我第一次拆的时候也是这个心态直到要做一个 2KB 以内的最小固件C 编译出来怎么都塞不下才回头去啃那份 .s 文件。它用 Keil5 的 armasm 手写启动代码、直接怼寄存器点灯、用 SysTick 搭节拍一行 C 都没有却把 Cortex-M3 从上电到跑起来的路子完整走了一遍。这份东西适合两类人想搞明白向量表、栈顶、分散加载这些“黑匣子”到底怎么排布的底层爱好者以及需要在现成的 C 工程里插一段汇编、做混合编程的开发者。看懂它再回头看 C 工程的启动流程很多玄学问题会一下子变得可解释。2. 工程骨架拆解从复位向量表到主循环的完整链路一个纯汇编工程看着文件少其实坑全在“哪些文件是必须的、哪些是 Keil5 自动生成的”这件事上。先把骨架摸清楚后面编译报错才不至于抓瞎。这个工程的结构大致是这样文件来源作用startup_stm32f103.s手写向量表、栈堆定义、Reset_Handlermain.s手写入口 main、主循环、业务逻辑gpio.s/delay.s手写GPIO 初始化、延时函数可拆可合systick.s手写SysTick 初始化与中断服务程序target.sct手写或自动分散加载决定 Flash/RAM 怎么切project.uvprojx生成工程文件记录器件型号、文件分组、编译选项Objects/*.o、*.hex、*.map生成目标文件、固件、地址映射表手写的那四个.s加一个.sct才是工程的“源码”剩下的都是构建产物删掉不影响编译。很多人拿到工程第一眼看到一堆.o、.crf、.uvguix以为都是必需品结果往 git 里一提交仓库直接膨胀好几倍。2.1 启动文件Cortex-M3 上电后的第一段代码Cortex-M3 复位后的行为是硬件写死的从地址0x08000000取第一个字装载 MSP取第二个字装载 PC。所以启动文件干的第一件事就是把这张表摆到 Flash 的最前面。; startup_stm32f103.s —— 纯汇编工程的最小启动文件 Stack_Size EQU 0x00000400 ; 1KB 栈够用但不铺张 AREA STACK, NOINIT, READWRITE, ALIGN3 Stack_Mem SPACE Stack_Size __initial_sp ; 标签落在栈的高地址端 PRESERVE8 ; 强制 8 字节栈对齐 THUMB ; 后续代码按 Thumb 编码 AREA RESET, DATA, READONLY EXPORT __Vectors __Vectors DCD __initial_sp ; 0x00 初始 MSP DCD Reset_Handler ; 0x04 复位入口 DCD NMI_Handler ; 0x08 DCD HardFault_Handler ; 0x0C ; ... 中间省略若干系统异常 DCD SysTick_Handler ; 0x3C 系统节拍 ; ... 后面接外设中断本工程只用了 SysTick这里有几个点必须理解透否则后面调试会很痛苦。DCD是“分配一个字并填入数值”它在 Flash 里连续排布形成的就是那张向量表SPACE只是保留空间不赋初值所以Stack_Mem在镜像里不占 Flash。__initial_sp这个标签之所以放在SPACE之后是因为 Cortex-M3 的栈是“满递减”的MSP 必须指向栈的最高地址压栈时先减后写。PRESERVE8容易被忽略——它告诉汇编器在函数入口保持 8 字节对齐AAPCS 要求栈指针在任何函数调用边界都是 8 的倍数少了这句调用 C 函数时可能在某些浮点或结构体拷贝场景直接挂掉。接着是复位的跳转逻辑AREA |.text|, CODE, READONLY EXPORT Reset_Handler IMPORT main Reset_Handler PROC LDR R0, main BLX R0 ; 跳进 main不回来 B . ; 万一返回就地死循环方便挂调试器 ENDPLDR R0, main不是一条真实指令汇编器会把它变成从字面量池literal pool取地址再把 main 的绝对地址装进 R0所以这里必须用BLX而不是BL——BL的相对跳转范围只有 ±16MB跨段调用不可靠。B .这个自跳转看着像凑数其实是血泪经验一旦 main 意外返回程序停在这里而不是跑飞到随机地址调试器一暂停就能看到 PC 卡在这一行比对着 HardFault 猜半天强得多。2.2 分散加载文件Flash 和 RAM 的边界到底谁说了算Keil5 在“Use Memory Layout from Target Dialog”勾选时会自动生成.sct但纯汇编工程最好手写一份因为向量表必须被强制放到镜像开头。; target.sct —— STM32F103C8 的典型布局 LR_IROM1 0x08000000 0x00010000 { ; 加载域64KB Flash ER_IROM1 0x08000000 0x00010000 { ; 执行域与加载域同址 *.o (RESET, First) ; 向量表强制排最前 *(InRoot$$Sections) .ANY (RO) ; 其余只读代码、常量 } RW_IRAM1 0x20000000 0x00005000 { ; 20KB SRAM .ANY (RW ZI) ; 已初始化变量 零初始化 } }*.o (RESET, First)这一行是整个文件的核心。它按“段名”而不是文件名来匹配凡是AREA RESET定义的内容都会被拎到最前面所以启动文件里的段名必须写成RESET写成RESET_DATA就对不上。First保证它排在所有内容之前这样0x08000000上一定是栈顶0x08000004上一定是Reset_Handler。RW_IRAM1里的RW ZI决定了两类数据带初值的全局变量以及需要清零的 BSS 段。这里埋了个坑——纯汇编工程如果不调用__mainKeil 的 C 库初始化流程不会执行RW 段的初值根本不会从 Flash 搬到 RAM变量上电就是随机值。工程里如果只写寄存器、不用带初值的全局变量那没事一旦用了就得自己写一段搬运循环或者老老实实把__main引进来。这个问题在第 5 章会展开说。2.3 Reset_Handler 到 main 之间还差什么C 工程的Reset_Handler里通常是一句LDR R0, __main由 C 库接管栈初始化、RW 搬运、BSS 清零最后才BL main。纯汇编工程把这套省略了换来的是启动时间从几百个周期降到十几个周期代价是所有初始化都得自己负责。我给这个工程的定位是“最小可用”所以跳过 C 库是有意的所有全局状态都用寄存器或绝对地址维护不给搬运环节留机会。如果要改成能跑 C 的混合工程正确做法是把Reset_Handler改回LDR R0, __main然后在工程里加上 C 库的启动文件这一改动在最后一章会具体演示。3. Keil5 环境搭建把 .s 文件变成能烧进片子的固件工程能打开不等于能编译能编译不等于能跑。这一章按“装—配—编—验”的顺序走一遍每一步都标清楚失败时看哪里。3.1 器件支持包与工程选项Device 选错一切白搭Keil5 装好之后第一件事是装器件支持包Device Family Pack在 Pack Installer 里找到 Cortex-M3 内核对应的 STM32F1 系列装完重启 IDE。新建工程时选STM32F103C8或你手上芯片的具体型号这一步会影响三样东西启动文件的默认模板、Flash 算法、调试时的寄存器视图。选错了不会立刻报错而是烧写时提示“Cannot access target”或者擦除失败非常容易误判成硬件问题。工程建好后要手动确认几个选项这几项在纯汇编工程里尤其关键选项位置设置项纯汇编工程该选什么Target 页Use MicroLIB不勾没有 C 库依赖Target 页Use Memory Layout from Target Dialog取消勾选改用手写 .sctOutput 页Create HEX File勾上方便脱机烧写Listing 页Assembler Listing勾上排查地址问题全靠它C/C 页不需要配置全空Use Memory Layout from Target Dialog取消勾选之后下面的 Scatter File 输入框才会激活把target.sct填进去。这一步如果漏了Keil 会按默认布局把向量表随便放0x08000000上就可能不是栈顶程序一上电直接跑飞。3.2 汇编器选项armasm 与 armclang 的语法分水岭Keil5 从某个版本开始把默认汇编器从 armasm 换成了 armclang 的 GNU 语法前端这直接决定了你手里的.s文件能不能编译通过。老工程的写法是AREA、EXPORT、PROC/ENDP新汇编器认的是.section、.global、.thumb两套语法完全不兼容。在 Options for Target → Asm 页里有一个Assembler Option下拉选armasm就沿用经典语法选armclang就得改源码。我一般这么做老工程保持 armasm 不动省得逐个文件改新起的工程直接在文件开头写.syntax unified走 GNU 路线因为新版本工具链对 armasm 的支持只会越来越弱。如果编译时出现A1137E: Unexpected characters at end of line或者A1586E: Bad symbol八成就是语法对不上。判断方法很简单打开.s文件看第一行是;注释还是注释;是 armasm和//是 GNU 风格。3.3 编译、下载与在线调试编译输出里最该看的不是 “0 Error(s)”而是最后那行Program Size: Codexxxx RO-dataxxxx RW-dataxxxx ZI-dataxxxx。纯汇编点灯工程Code 通常在几百字节到 1KB 之间如果突然涨到 4KB 以上说明链接器把不该进来的东西拉进来了多半是.sct里的.ANY匹配范围太宽。下载配置在 Options → Debug 页选ST-Link Debugger或CMSIS-DAP点 Settings 进 Flash Download 页确认Programming Algorithm里加的是STM32F10x Med-density Flash对应 64KB/128KB 型号勾上Reset and Run。这一步翻车最多算法选成 High-density烧写会报 “Flash Download failed”因为擦除命令的地址范围对不上。调试阶段我习惯开两个窗口——Registers 窗口盯 R13(SP)、R15(PC) 和 xPSRDisassembly 窗口看反汇编。上电复位后立刻暂停PC 应该停在0x08000004附近的Reset_HandlerSP 应该是个0x2000xxxx的值。这两个数不对后面的代码写得再对也没用。3.4 用 map 文件核对固件真的对编译完在Objects/或工程根目录会生成.map文件这是验证布局的唯一可靠依据。打开搜Image Entry point应该指向Reset_Handler搜__initial_sp应该是个 RAM 高地址搜Execution Region ER_IROM1Base 必须是0x08000000。Image Entry point : 0x08000009 ... __initial_sp 0x20000400 Data 4 startup_stm32f103.o(STACK)0x08000009这个奇数不是笔误而是 Thumb 状态的标志位——Cortex-M3 只支持 Thumb 指令集函数指针的最低位必须置 1硬件跳转时会自动清掉。如果 map 里看到入口地址是0x08000008这种偶数说明某处丢了THUMB属性跳过去必然进 HardFault。我第一次遇到时对着代码看了两小时最后在 map 文件里找到答案从那以后每次编译完都先扫一眼这个值。4. 核心模块拆解寄存器、延时与节拍的三件套骨架搭好之后真正干活的就是三个模块GPIO、延时、SysTick。这三个加起来不到 100 行汇编但每一条指令的意图都值得说清楚。4.1 GPIO 直接操作三行代码点亮一个 LED用 C 的时候 HAL 库把寄存器包装得严严实实写汇编就没这层遮羞布了每个地址都得自己查手册。; gpio.s —— PB0 推挽输出初始化 GPIOB_BASE EQU 0x40010C00 GPIOB_CRL EQU GPIOB_BASE 0x00 ; 端口配置低寄存器 GPIOB_BSRR EQU GPIOB_BASE 0x10 ; 置位/复位寄存器 RCC_APB2ENR EQU 0x40021018 ; APB2 外设时钟使能 AREA |.text|, CODE, READONLY EXPORT GPIOB_Init THUMB GPIOB_Init PROC LDR R0, RCC_APB2ENR LDR R1, [R0] ORR R1, R1, #(1 3) ; bit3 IOPBEN开 GPIOB 时钟 STR R1, [R0] LDR R0, GPIOB_CRL LDR R1, [R0] BIC R1, R1, #0x0000000F ; 清掉 PB0 的 4 位配置 ORR R1, R1, #0x00000003 ; MODE11 输出 50MHz, CNF00 推挽 STR R1, [R0] BX LR ENDP这里的关键是BICORR这个组合而不是直接STR一个常量。GPIOB_CRL一个寄存器管 8 个引脚每个引脚 4 位直接写常量会把其他引脚的配置一起冲掉。先BIC清零目标位、再ORR置位是寄存器编程的标准做法C 里的 ~mask; | value;编译出来也是这两条。时钟使能必须放在配置之前这个顺序不能反。RCC_APB2ENR的 bit3 对应 GPIOB写 1 之后外设才有时钟此前的任何写操作都是无效的。我见过有人把时钟使能写在初始化函数末尾结果引脚就是不响应查了半天以为是硬件虚焊。点亮 LED 用 BSRR 而不是 ODR因为 BSRR 是原子操作低 16 位写 1 置位、高 16 位写 1 复位写 0 的位不受影响。用 ODR 做“读—改—写”在中断环境下会被打断BSRR 不存在这个问题。; 主循环里翻转 PB0 Loop LDR R0, GPIOB_BSRR LDR R1, 0x00000001 ; BS0置位 PB0 STR R1, [R0] LDR R0, 500 BL Delay_ms LDR R0, GPIOB_BSRR LDR R1, 0x00010000 ; BR0复位 PB0 STR R1, [R0] LDR R0, 500 BL Delay_ms B Loop注意每次BL之前都要重新LDR R0, 500因为按 AAPCS 规定 R0~R3 是调用者保存寄存器被调函数可以随意改写。这一点在汇编里没有任何保护忘了就等着看 LED 闪得莫名其妙。4.2 软件延时一个双层循环的时序估算没有定时器的时候延时只能靠空转。这段代码简单但估算方法值得说清楚。; delay.s —— 粗略毫秒延时入参 R0 毫秒数 Delay_ms PROC PUSH {R1, R2} ; 保存将被改写的寄存器 LDR R1, 7200 ; 内层计数见下方估算 Outer MOV R2, R1 Inner SUBS R2, R2, #1 BNE Inner SUBS R0, R0, #1 BNE Outer POP {R1, R2} BX LR ENDP估算逻辑是这样的72MHz 主频下SUBSBNE这两条指令在 Flash 里执行约 3~4 个周期流水线有分支开销所以要凑 1ms 的 72000 个周期内层计数取 7200 左右。这个数字是拍脑袋出来的实际误差可能到 ±20%因为 Flash 等待周期、流水线状态、中断抢占都会影响。想要更准把内层计数值调到 9000 再实测一次——用示波器量一个 100ms 的方波周期反推出实际系数。我一般会在注释里写上“实测 72MHz / 等待周期 2 时取 9000”这种具体条件因为换个主频、改个 Flash 等待配置这个数字就全变了不写清楚下次自己都看不懂。PUSH {R1, R2}这两行不能省。虽然在这个工程里调用者恰好没用到 R1、R2但只要函数被复用就可能踩到“被调函数悄悄改了寄存器”的坑而这种 bug 往往在改了几十行之后才爆发定位成本极高。4.3 SysTick 与中断向量把节拍交给硬件软件延时占着 CPU 空转想要一边闪灯一边干别的就得用 SysTick。; systick.s —— 1ms 系统节拍 SYST_CSR EQU 0xE000E010 SYST_RVR EQU 0xE000E014 SYST_CVR EQU 0xE000E018 AREA |.text|, CODE, READONLY EXPORT SysTick_Init EXPORT SysTick_Handler IMPORT Tick_Count SysTick_Init PROC LDR R0, SYST_RVR LDR R1, 71999 ; 72MHz / 1000 - 1 STR R1, [R0] LDR R0, SYST_CVR MOV R1, #0 STR R1, [R0] ; 清计数器避免首拍不准 LDR R0, SYST_CSR MOV R1, #0x07 ; CLKSOURCE|TICKINT|ENABLE STR R1, [R0] BX LR ENDP SysTick_Handler PROC LDR R0, Tick_Count LDR R1, [R0] ADDS R1, R1, #1 STR R1, [R0] BX LR ENDP0x07这三个位分别是bit0 使能计数器、bit1 使能中断、bit2 选择内核时钟不选的话走 HCLK/8。LOAD值等于重装载值计数器从 LOAD 递减到 0 触发中断所以 1ms 要填 71999 而不是 72000。SysTick_Handler这个名字必须和向量表里DCD的那一项完全一致而且必须EXPORT否则链接器看不到向量表里那一项会被填成 0中断一触发就跳进 HardFault。这是纯汇编工程最常见的问题之一比 C 工程更容易犯因为 C 里通常有统一的stm32f1xx_it.c兜底汇编里没有。中断服务程序的返回值必须用BX LR不能用POP {PC}或者B回跳。异常返回时硬件会从栈里恢复 R0~R3、R12、LR、PC、xPSRBX LR里那个特殊值0xFFFFFFF9就是告诉内核“走异常返回流程”。5. 避坑与排查汇编工程里最容易翻车的五处汇编不像 C编译器不会帮你兜任何东西错了就是错了而且错误现象往往离真正的原因很远。下面五条都是我在实际调试中撞过的按“现象—原因—解决”整理。5.1 编译报 Undefined symbol但函数明明写了现象编译时报A1137E: Undefined symbol SysTick_Handler可文件里确实有SysTick_Handler PROC。原因PROC/ENDP只是标记函数边界不改变符号的可见性跨文件引用必须显式EXPORT。反过来的情况也常见——在本文件里用IMPORT声明的符号如果实际定义处没EXPORT链接一样失败。解决所有会被向量表DCD引用、或者被其他.s文件BL的函数一律加EXPORT 函数名。习惯做法是在每个.s文件头部集中放一组EXPORT比散落在函数前面更容易查。5.2 烧写成功但不运行PC 停在莫名其妙的地方现象Flash 下载显示成功按复位键什么都没发生调试器暂停后 PC 指向0x08000000或者某个非法地址。原因向量表没被放到镜像开头。要么.sct里漏了*.o (RESET, First)要么启动文件里的AREA段名写成了别的比如RESET_DATA导致链接器匹配不上向量表被当成普通只读数据排到了后面。解决打开.map文件搜Image Entry point正常应该是0x08000009这种奇数。如果 Base 不是0x08000000回到.sct逐字核对段名。另外确认 Options 里Use Memory Layout from Target Dialog已取消勾选否则手写.sct根本不生效。5.3 全局变量上电是随机值现象定义了一个带初值的全局计数变量期望上电从 0 开始实际读到的是乱码。原因纯汇编工程没有调用__mainKeil 的 C 库初始化流程没跑RW 段的初值还在 Flash 里躺着没被搬进 RAM。.sct写的RW只是告诉链接器“这块地址归你”不代表会有人去搬运。解决要么在Reset_Handler里手写一段搬运循环从Load$$RW_IRAM1$$Base拷到Image$$RW_IRAM1$$Base长度取Image$$RW_IRAM1$$Length要么干脆不用带初值的全局变量全部用寄存器传参。我选后者因为纯汇编工程的定位就是“极简”为了一个变量引入散加载搬运不划算。5.4 LDR 伪指令编译报错或取到错误地址现象LDR R0, 0x40021018报A1516E: Immediate too large或者编译通过了但取到的值不对。原因LDR Rd, expr是伪指令汇编器会把它变成 PC 相对的字面量加载。字面量池默认放在当前段末尾或者下一个LTORG处如果池子距离指令超过 4KBThumb 的 PC 相对寻址范围汇编器就报错。解决在两个函数之间手动插一行LTORG强制在此处倾倒字面量池。大段代码中间隔几百行就补一个不要指望汇编器自动处理。另一个办法是用MOVW/MOVT组合直接构造 32 位常量不依赖字面量池代价是占两条指令。5.5 单步调试时一进中断就掉 HardFault现象主循环跑得好好的一开中断立刻进 HardFault栈里翻出来的 PC 指向向量表某个空项。原因中断服务程序没EXPORT或者名字和向量表里的DCD不一致链接器把这个符号当成未定义向量表对应位置填了 0。还有一种情况是处理函数里用了 R4~R11 却没PUSH异常返回后主流程的寄存器被改坏。解决把所有中断处理函数集中在一个文件里向量表的DCD列表和函数定义一一对照着看。处理函数里只碰 R0~R3 和 R12硬件自动保存要用 R4 以上必须PUSH {R4, LR}、结尾POP {R4, PC}用POP {PC}一样能触发异常返回还省一条指令。6. 二次开发把汇编模块挂进 C 工程纯汇编跑通了实际项目里更常见的是反过来——主体用 C只有某几个对时序或体积极其敏感的函数用汇编写。这时候要做的是混合编程关键是守住 AAPCS 那套调用约定。最省事的做法是保留 C 工程的启动文件和__main把汇编文件当成一个普通模块加进分组。汇编侧要做的就两件事EXPORT出去给 C 调IMPORT进来调 C。; crc16.s —— 给 C 工程提供 CRC16 查表加速函数 AREA |.text|, CODE, READONLY EXPORT crc16_asm ; C 侧声明 extern uint16_t crc16_asm(...) THUMB ; uint16_t crc16_asm(uint16_t crc, const uint8_t *buf, uint32_t len) ; 入参R0crc, R1buf, R2len 返回R0 crc16_asm PROC PUSH {R4, LR} ; 只用到 R4顺手把 LR 也压了 CMP R2, #0 BEQ done loop LDRB R3, [R1], #1 ; 取一字节并后自增 EOR R3, R3, R0, LSR #8 LDR R4, crc_table ; 表在 C 侧定义并 extern LDRH R3, [R4, R3, LSL #1] ; 半字索引偏移 idx*2 EOR R0, R3, R0, LSL #8 SUBS R2, R2, #1 BNE loop done UXTH R0, R0 ; 只保留低 16 位 POP {R4, PC} ENDP这段代码里几个点必须对上入参顺序是 R0、R1、R2返回值放 R0PUSH {R4, LR}保证 8 字节对齐两条寄存器正好 8 字节同时保住 R4 和返回地址POP {R4, PC}一次完成恢复和返回。C 侧只需要一句extern uint16_t crc16_asm(uint16_t crc, const uint8_t *buf, uint32_t len);链接时把.s和.c一起编进去就行。验证方法我固定用三步先用 C 写一份参考实现跑同一组测试向量对比结果再用调试器看汇编函数的入口处 R0~R2 是否等于 C 传进来的值不等就是参数传递出了问题最后在函数返回后检查 R4 有没有被改回去寄存器窗口里对比调用前后的值。这三步走完混合编程基本不会再出问题。从那以后我每次往 C 工程里塞汇编函数都会先在注释里把入参寄存器、返回值寄存器、会破坏哪些寄存器写清楚再让 C 侧调用一次并对比参考实现——省下的这点时间远不如后面定位一个“R4 被悄悄改掉导致主流程跑飞”的代价。希望帮到你。本文还有配套的精品资源点击获取
返回列表
PREV
查看更多资讯
NEXT
返回资讯列表