1、嵌入式处理器基础 典型的微处理器由控制单元、程序计数器（PC）、指令寄存器（IR）、数据通道、存储器等组成 。 指令执行过程一般分为： 取指： 从存储器中获得下一条执行的指令读入指令寄存器； PC: 程序计数器, 总是指向下一条将要执行的指令； IR: 指令寄存器，用于保持已取得指令；如图： 译码： 解释指令，决定指令的执行意义；如图： 执行： 从存储器向数据通道寄存器移动数据； 通过算术逻辑单元ALU进行数据操作；如图： 存储： 从寄存器向存储器写数据。如图： 在一些微处理器上，如ARM系列处理器、DSP等，指令实现流水线作业，指令过程按流水线的数目来进行划分。如5级流水线的处理器将指令分5个阶段执行。 （1）按存储结构分：冯·诺依曼体系结构和哈佛体系结构 冯·诺伊曼结构也称普林斯顿结构，是一种将程序指令存储器和数据存储器合并在一起的存储器结构。 处理器，经由同一个总线传输来访问程序和数据存储器，程序指令和数据的宽度相同。如X86系列、ARM7等，如图： 哈佛结构是一种将程序指令存储和数据存储分开的存储器结构，目的是为了减轻程序运行时的访存瓶颈。哈佛结构的微处理器通常具有较高的执行效率。 Microchip公司的PIC系列芯片，摩托罗拉公司的MC68系列、Zilog公司的Z8系列、ATMEL公司的AVR系列和ARM公司的ARM9、ARM10和ARM11 等。如图： 按指令类型可分为：复杂指令集（CISC）处理器和精简指令集（RISC）处理器 。 CISC：复杂指令集（Complex Instru ction Set Computer）； 具有大量的指令和寻址方式，那么就需要更多的解释器。 8/2原则：80%的程序只使用20%的指令； 大多数程序只使用少量的指令就能够运行。 CISC具有如下显著特点： (1) 指令格式不固定，指令长度不一致，操作数可多可少； (2) 寻址方式复杂多样，以利于程序的编写； (3) 采用微程序结构，执行每条指令均需完成一个微指令序列； (4) 每条指令需要若干个机器周期才能完成，指令越复杂，花费的机器周期越多。 RISC：精简指令集（Reduced Instruction Set Computer)：指令数目少，在通道中只包含最有用的指令；执行时间短，确保数据通道快速执行每一条指令；使CPU硬件结构设计变得更为简单；每条指令都采用标准字长。 2、ARM处理器体系架构 ARM即Advanced RISC Machines的缩写。 1985年4月26日，第一个ARM原型在英国剑桥的Acorn计算机有限公司诞生。 20世纪80年代后期，ARM很快开发成Acorn的台式机产品，形成英国的计算机教育基础。 1990年成立了Advanced RISC Machines Limited。 20世纪90年代，ARM32位嵌人式RISC（Reduced Instruction Set Computer）处理器扩展到世界范围，占据了低功耗、低成本和高性能的嵌入式系统应用领域的领先地位。 目前己经占有75%以上的32位嵌入式产品市场。 32位RISC处理器受到青睐，领先的是ARM嵌入式微处理器系列。 ARM公司虽然只成立20多年，但在1999年因移动电话火爆市场，其32位RISC处理器占市场份额超过了50%，2001年初，ARM公司的32位RISC处理器市场占有率超过了75%。ARM公司是知识产权供应商，是设计公司。由合作伙伴公司来生产各具特色的芯片。 ARM处理器特点： （1）ARM指令是32位定长的（除AArch64架构部分增加指令为64位外） （2）寄存器数量丰富（37个寄存器） （3）普通的Load/Store指令 （4）多寄存器的Load/Store指令 （5）指令的条件执行 （6）单时钟周期中的单条指令完成数据移位操作和ALU操作 （7）通过变种和协处理器来扩展ARM处理器的功能 （8）扩展了16位的Thumb指令来提高代码密度 ARM的命名规则, 大致分成两类类： 基于ARM Architecture版本的“处理器系列”命名规则； 基于ARM Architecture版本的“处理器型号”命名规则。 ARMv6 架构，引进了包括单指令多数据(SIMD)运算在内的一系列新功能。 ARMv6-M 架构，为低成本、高性能设备而设计，向以前由8位设备占主导地位的市场提供32位功能强大的解决方案。如Cortex™-M0和Cortex-M1。 ARMv7架构，所有ARMv7架构处理器都实现了Thumb-2 技术（一个经过优化的16/32位混合指令集），此架构分为3类处理器：Cortex-A -应用处理器、Cortex-R - 实时处理器、Cortex-M - 微控制器。 ARMv8架构，ARMv8-A将64位体系结构支持引入ARM体系结构中，其中包括：64位通用寄存器、SP（堆栈指针）和 PC（程序计数器），64位数据处理和扩展的虚拟寻址，兼容32位处理。 ARMv9架构，最重大的升级在于AI和安全，在兼容ARMv8的基础上，提升了安全性，增加了矢量计算、机器学习和数据信号处理等多方面能力，性能表现也将得到极大幅度的提升。 1）ARM数据类型 （1）双字节（Double-Word）：64位 （2）字（Word）：在ARM体系结构中，字的长度为32位。 （3）半字（Half-Word）：在ARM体系结构中，半字的长度为16位。 （4）字节（Byte）：在ARM体系结构中，字节的长度为8位。 2）ARM处理器存储格式 作为32位的微处理器，ARM体系结构所支持的最大寻址空间为4GB。 ARM体系结构可以用两种方法存储字数据，分别为大端模式和小端模式。 大端模式（高地高低）：字的高字节存储在低地址字节单元中，字的低字节存储在高地址字节单元中。 3）ARM处理器工作状态 从编程的角度来看，ARM微处理器的工作状态一般ARM和Thumb有两种，并可在两种状态之间切换。 （1）ARM状态：此时处理器执行32位的字对齐ARM指令，绝大部分工作在此状态。 （2）Thumb状态：此时处理器执行16位的半字对齐的Thumb指令。 THUMB指令的特点： THUMB代码所需空间为ARM代码的70%； THUMB代码所使用的指令数比ARM代码多40%； 用32位存储器，ARM代码比THUMB代码快40%； 用16位存储器，THUMB代码比ARM代码快45%； 使用THUMB代码，外部存储器功耗比ARM代码少30% 4）ARM处理器工作模式 5）ARM Cortex-A处理器工作模式 6） Cortex-A寄存器组 34个通用寄存器，包括各种模式下的R0-R14和共用的R15程序计数器(PC)，这些寄存器都是32位的。8个状态寄存器，Hyp模式独有一个ELR_Hyp寄存器。 7）程序状态寄存器CPSR和SPSR 和其他处理器一样，ARM有程序状态存储器来配置处理器工作模式和显示工作状态。ARM处理器有两个程序状态寄存器CPSR （Current Program Status Register，当前程序状态寄存器）和SPSR （Saved Program Status Register，备份的程序状态寄存器）。 CPSR可在任何运行模式下被访问，它包括条件标志位、中断禁止位、当前处理器模式标志位以及其他一些相关的控制和状态位。 每一种运行模式下都有一个专用的物理状态寄存器，称为SPSR为状态寄存器。 （1）N（Negative）：当用两个补码表示的带符号数进行运算时，N=1表示结果为负，N=0表示结果为正数或零 （2）Z（Zero）：Z=1表示运算结果为0，Z=0表示运算结果非零 （3）C（Carry）：有4种方法可以设置C的值： 1）加法指令（包括比较指令CMP） 2）当运算产生进位时（无符号数溢出），C=1，否则C=0 3）减法运算（包括比较指令CMP） 4）当运算产生了借位（无符号数溢出），C=0，否则C=1 对于包含移位操作的非加/减运算指令，C为移出值的最后一位。对于其他的非加/减运算指令，C的值通常不变。 （4）V（Overflow）：有2种方法设置V的值： 1）对于加/减法运算指令，当操作数和运算结果为二进制的补码表示的带符号数时，V=1表示符号位溢出。 2）对于其他的非加减法运算指令，V的值通常不变。 （5）I（Interrupt Request）：I=1表示禁止响应irq，I=0表示允许响应 （6）F（Fast Interrupt Request）：F=1表示禁止响应fiq，F=0表示允许响应 （7）T（Thumb）：T=0表示当前状态位ARM状态，T=1表示为Thumb状态 （8）M4-M0：表示当前处理器的工作模式 8）工作模式的切换条件 （1）执行软中断（SWI）或复位命令（Reset）指令。如果在用户模式下执行SWI指令，CPU就进入管理（Supervisor）模式。 （2）有外部中断发生。如果发生了外部中断，CPU就会进入IRQ或FIQ模式。 （3）CPU执行过程中产生异常。最典型的异常是由于MMU保护所引起的内存访问异常，此时CPU会切换到Abort模式。如果是无效指令，则会进入Undefined模式。 （4）有一种模式是CPU无法自动进入的，这种模式就是System模式，要进入System模式必须由程序员编写指令来实现。要进入System模式只需改变CPSR的模式位为System模式对应的模式位即可。 （5）在任何特权模式下，都可以通过修改CPSR的MODE域来进入其他模式。不过需要注意的是由于修改的CPSR是该模式下的影子CPSR，即SPSR，因此并不是实际的CPSR，所以一般的做法是修改影子CPSR，然后执行一个MOVS指令来恢复执行某个断点并切换到新模式。 3、ARM处理器内存管理 1）什么是内存映射 内存映射指的是在ARM存储系统中，使用内存管理单元(MMU)实现虚拟地址到实际物理地址的映射，如图所示。 2）为什么要内存映射 A32架构的ARM的地址总线为32位，故CPU可寻址范围为0x00000000~0xffffffff寻址空间为4GB，所有的内部和外部存储或者外设单元都需要通过对应的地址来操作，不同芯片外设的种类数量寻址空间都不一样，为了能让内核更方便的管理不同的芯片设计，ARM内核会先给出预定义的存储映射。 芯片设计公司需要根据内核提供的预定义的存储器映射来定义芯片内部外设和外部的保留接口，这样做的好处是极大地减少了同一内核不同芯片间地址转化的麻烦（CPU操作统一的虚拟地址，实际物理地址交由MMU管理）。 3）位带操作 （1）什么是位带操作 举个简单的例子，在使用51单片机操作P1.0为低电平时我们知道这背后实际上就是往某个寄存器某个比特位中写1或0的过程，但在CPU操作的过程中每一个地址所对应的都是一个8位字节，怎么实现对其中某一位的直接操作，这就需要位带操作的帮助。 （2）哪些地址可以进行位带操作 上图中有两个区中实现了位带。其中一个是 SRAM 区的最低 1MB 范围（Bit band region），第二个则是片内外设区的最低 1MB 范围。 4）寄存器的地址计算 在ARM中所有的外设地址基本都是挂载在AHB或者APBx总线上，因此我们往往采用基地址+偏移地址+结构体的方式，来快速明了计算某一外设具体寄存器的地址，如图所示。 5）集成外设寄存器访问方法
1、MCU最开始一启动后去哪里读代码？CPU上电启动后被设计为去地址0x00000000位置处读取代码；首先会连续读取两个字，分别是栈指针初始值和复位异常处理函数的地址；然后跳去执行复位异常处理函数。 当然在一些早期的ARM处理器设计中，如Arm7TDMI，复位后会直接读取0地址处的代码进行执行，由软件初始化栈指针，0地址处存放的直接就是中断处理函数，而不是函数地址。 所以我们可以有理由推测出，第一个字是栈地址是因为接下来的复位中断处理函数涉及函数跳转，可能已经需要存放内容在栈里了。 2. 0x0地址处是bootROM代码吗，还是用户bootloader代码？ 答案是都可以。这其实取决于用户的代码是存放在哪里的。比如说对于一些性能强的MCU（如Cortex-A系列）来说，代码本身体积比较大，存放在SD卡里或者QSPI/SPI Flash里都有可能，这些MCU启动一定是先去bootROM执行代码，因为SD卡、SPI Flash的储存不在MCU的统一编址空间里，没初始化这些外设前根本无法访问，bootROM这块Nor Flash就一定是可以被MCU直接通过总线地址访问的，0地址的代码位于bootROM中。代码从bootROM中起来后，通过启动引脚判断从哪个外设中搬用户程序，并去初始化相应外设，将外设中存储的用户代码搬到内部SRAM中执行。后续的启动流程不赘述。 对于一些小容量的MCU来说，比如Cortex-M3/M4，他们的芯片里有内置Flash，这个Flash的特点跟上面说的bootROM很像，是MCU可以直接通过地址总线去访问到的，不需要进行外设初始化的。当然，这些MCU内部也是有bootROM的，因此这些MCU一上电可以选择从bootROM中启动，也可以选择从内置Flash中启动，是通过外部引脚进行选择的，选择了谁，就把谁的起始地址映射到0地址处。 3. 类似Cortex-M3/M4是如何保证Flash起始地址是栈指针和复位异常处理函数指针的？ 这一点实际是通过编译的链接文件制定的。比如说如下是我截取的IAR的链接文件.icf。 4. MCU有可能不从0地址开始读代码吗？ M7内核芯片比较灵活了，改变了固定从0x0000 0000地址读取中断向量表的问题，以STM32H7为例，可以从 0x0000 0000 到 0x3FFF 0000 所有地址进行启动。专门安排了个选项字节来配置。
在刚开始接触STM32的时候，使用的keil作为IDE，由于在这之前，使用过VS， 使用过eclipse，因而在使用keil之后，实在难以忍受keil编辑器简陋的功能，可以说是极其糟糕的写代码体验。 之后，尝试过各种IDE，使用eclipse+keil，结果发现eclipse对C语言的支持也是鸡肋，使用emBits+gcc，需要和其他人协同的话就比较麻烦，之后发现了platformIO，也是使用gcc作为编译器，不过只支持HAL库，而且还有一个重要的原因，同事都是用的keil，如果我使用gcc，就不能协同工作了。 最后，通过使用VS Code + keil的方式，完美解决了写代码的体验问题，以及工程协作问题，其实网上使用VS Code作为编辑器，keil作为编译器的教程很多，不过基本都是需要在VS Code中编辑，然后在keil中编译，下载，调试，本文就要实现编辑，编译，下载，调试，全部使用VS Code。 Part1环境 （1）VS Code； （2）keil；python； （3）GNU Arm Embedded Toolchain（arm gcc工具链）； （4）C/C++(VS Code 插件)； （5）Cortex-Debug(VS Code 插件)； （6）其他VS Code插件(提升体验)。 Part2前提 正式写代码之前，首先需要建立好一个工程，这个需要使用keil完成，包括工程配置，文件添加… Part3编辑 在安装好VS Code插件之后，VS Code编写C代码本身体验就已经很好了， 但是，因为我们使用的是keil环境，所以需要配置头文件包含，宏定义等，在工程路径的.vscode文件夹下打开c_cpp_properties.json文件，没有自己新建一个，内容配置如下： { "configurations": [ { "name": "STM32", "includePath": [ "D:/Program Files/MDK5/ARM/ARMCC/**", "${workspaceFolder}/**", "" ], "browse": { "limitSymbolsToIncludedHeaders": true, "databaseFilename": "${workspaceRoot}/.vscode/.browse.c_cpp.db", "path": [ "D:/Program Files/MDK5/ARM/ARMCC/**", "${workspaceFolder}/**", "" ] }, "defines": [ "_DEBUG", "UNICODE", "_UNICODE", "__CC_ARM", "USE_STDPERIPH_DRIVER", "STM32F10X_MD" ], "intelliSenseMode": "msvc-x64" } ], "version": 4 } 其中，需要在includePath和path中添加头文件路径，${workspaceFolder}/**是工程路径，不用改动，额外需要添加的是keil的头文件路径， 然后在defines中添加宏，也就是在keil的Options for Target的C++选项卡中配置的宏，然后就可以体验VS Code强大的代码提示，函数跳转等功能了（甩keil的编辑器一整个时代）。 Part4编译、烧录 编译和烧录通过VS Code的Task功能实现，通过Task，使用命令行的方式调用keil进行编译和烧录。 keil本身就支持命令行调用，具体可以参考keil的手册，这里就不多说了，但是问题在于，使用命令行调用keil，不管是什么操作，他的输出都不会输出到控制台上！！！(要你这命令行支持有何用) 不过好在，keil支持输出到文件中，那我们就只能利用这个做点骚操作了。一边执行命令，一边读取文件内容并打印到控制台，从而就实现了输出在控制台上，我们就能直接在VS Code中看到编译过程了 为此，我编写了一个Python脚本，实现keil的命令行调用并同时读取文件输出到控制台。 #!/usr/bin/python # -*- coding:UTF-8 -*- import os import threading import sys runing = True def readfile(logfile): with open(logfile, 'w') as f: pass with open(logfile, 'r') as f: while runing: line = f.readline(1000) if line != '': line = line.replace('\\', '/') print(line, end = '') if __name__ == '__main__': modulePath = os.path.abspath(os.curdir) logfile = modulePath + '/build.log' cmd = '\"D:/Program Files/MDK5/UV4/UV4.exe\" ' for i in range(1, len(sys.argv)): cmd += sys.argv[i] + ' ' cmd += '-j0 -o ' + logfile thread = threading.Thread(target=readfile, args=(logfile,)) thread.start() code = os.system(cmd) runing = False thread.join() sys.exit(code) 此脚本需要结合VS Code的Task运行，通过配置Task，我们还需要匹配输出中的错误信息(编译错误)，实现在keil中，点击错误直接跳转到错误代码处，具体如何配置请参考VS Code的文档，这里给出我的Task。 { // See https://go.microsoft.com/fwlink/?LinkId=733558 // for the documentation about the tasks.json format "version": "2.0.0", "tasks": [ { "label": "build", "type": "shell", "command": "py", "args": [ "-3", "${workspaceFolder}/scripts/build.py", "-b", "${config:uvprojxPath}" ], "group": { "kind": "build", "isDefault": true }, "problemMatcher": [ { "owner": "c", "fileLocation": [ "relative", "${workspaceFolder}/Project" ], "pattern": { "regexp": "^(.*)\\((\\d+)\\):\\s+(warning|error):\\s+(.*):\\s+(.*)$", "file": 1, "line": 2, "severity": 3, "code": 4, "message": 5 } } ] }, { "label": "rebuild", "type": "shell", "command": "py", "args": [ "-3", "${workspaceFolder}/scripts/build.py", "-r", "${config:uvprojxPath}" ], "group": "build", "problemMatcher": [ { "owner": "c", "fileLocation": [ "relative", "${workspaceFolder}/Project" ], "pattern": { "regexp": "^(.*)\\((\\d+)\\):\\s+(warning|error):\\s+(.*):\\s+(.*)$", "file": 1, "line": 2, "severity": 3, "code": 4, "message": 5 } } ] }, { "label": "download", "type": "shell", "command": "py", "args": [ "-3", "E:\\Work\\Store\\MyWork\\STM32F1\\FreeModbus_M3\\scripts\\build.py", "-f", "${config:uvprojxPath}" ], "group": "test" }, { "label": "open in keil", "type": "process", "command": "${config:uvPath}", "args": [ "${config:uvprojxPath}" ], "group": "test" } ] } 对于使用ARM Compiler 6编译的工程，build和rebuild中的problemMatcher应该配置为： "problemMatcher": [ { "owner": "c", "fileLocation": ["relative", "${workspaceFolder}/MDK-ARM"], "pattern": { "regexp": "^(.*)\\((\\d+)\\):\\s+(warning|error):\\s+(.*)$", "file": 1, "line": 2, "severity": 3, "message": 4, } } ] 文件中的config:uvPath和config:uvprojxPath分别为keil的UV4.exe文件路径和工程路径(.uvprojx)，可以直接修改为具体路径，或者在VS Code的setting.json中增加对应的项，至此，我们已经完美实现了在VS Code中编辑，编译，下载了。 编译输出： 有错误时输出： 错误匹配： Part5调试 调试需要使用到Cortex-Debug插件，以及arm gcc工具链，这部分可以参考Cortex-Debug的文档，说的比较详细； 首先安装Cortex-Debug插件和arm gcc工具链，然后配置好环境路径，如果使用Jlink调试，需要下载Jlink套件，安转好之后，找到JLinkGDBServerCL.exe这个程序，在VS Code的设置中添加"cortex-debug.JLinkGDBServerPath": "C:/Program Files (x86)/SEGGER/JLink/JLinkGDBServerCL.exe"，后面的路径是你自己的路径。 这里补充一下arm gcc工具链的配置："cortex-debug.armToolchainPath": "D:\\Program Files (x86)\\GNU Arm Embedded Toolchain\\9 2020-q2-update\\bin",后面的路径是你自己的路径。如果使用STLink调试，需要下载stutil工具，在GitHub上搜索即可找到，同样配置好路径即可。 以上步骤弄好之后，可以直接点击VS Code的调试按钮，此时会新建luanch.json文件，这个文件就是VS Code的调试配置文件，可参考我的文件进行配置。 { // 使用 IntelliSense 了解相关属性。 // 悬停以查看现有属性的描述。 // 欲了解更多信息，请访问: https://go.microsoft.com/fwlink/?linkid=830387 "version": "0.2.0", "configurations": [ { "name": "Cortex Debug(JLINK)", "cwd": "${workspaceRoot}", "executable": "${workspaceRoot}/Project/Objects/Demo.axf", "request": "attach", "type": "cortex-debug", "servertype": "jlink", "device": "STM32F103C8", "svdFile": "D:\\Program Files\\ARM\\Packs\\Keil\\STM32F1xx_DFP\\2.3.0\\SVD\\STM32F103xx.svd", "interface": "swd", "ipAddress": null, "serialNumber": null }, { "name": "Cortex Debug(ST-LINK)", "cwd": "${workspaceRoot}", "executable": "${workspaceRoot}/Project/Objects/Demo.axf", "request": "attach", "type": "cortex-debug", "servertype": "stutil", "svdFile": "D:\\Program Files\\ARM\\Packs\\Keil\\STM32F1xx_DFP\\2.3.0\\SVD\\STM32F103xx.svd", "device": "STM32F103C8", "v1": false } ] } 注意其中几个需要修改的地方，executable修改为你的工程生成的目标文件，也就是工程的.axf文件，svdFile用于对MCU外设的监控，该文件可以在keil的安装路径中找到，可以参考我的路径去找，配置完成后，再次点击调试按钮即可进行调试。 相比keil自己的调试功能，VS Code还支持条件断点，可以设置命中条件，次数等，可以极大的方便调试。 总结 通过以上的配置，我们基本上，除了建立工程和往工程中添加文件，其他完全不需要打开keil，所以也无妨说一句，再见，智障keil！
【前面的话】在近几年的嵌入式社区中，流传着不少关于面相Cortex-M的Bootloader科普文章，借助这些文章，一些较为经典的代码片断和技巧得到了广泛的传播。 在从Bootloader跳转到用户APP的过程中，使用函数指针而非传统的汇编代码则成了一个家喻户晓的小技巧。相信类似下面 JumpToApp() 函数，你一定不会感到陌生： typedef void (*pFunction)(void); void JumpToApp(uint32_t addr){ pFunction Jump_To_Application; __IO uint32_t StackAddr; __IO uint32_t ResetVector; __IO uint32_t JumpMask; JumpMask = ~((MCU_SIZE-1)|0xD000FFFF); if (((*(__IO uint32_t *)addr) & JumpMask ) == 0x20000000) //�ж�SPָ��λ�� { StackAddr = *(__IO uint32_t*)addr; ResetVector = *(__IO uint32_t *)(addr + 4); __set_MSP(StackAddr); Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); }} 为了读懂这段代码，需要一些从事Cortex-M开发所需的“热知识”： 向量表是一个由 32bit 数据构成的数组 数组的第一个元素是 uintptr_t 类型的指针，保存着复位后主栈顶指针（MSP）的初始值。 从数组第二个元素开始，保存的是 (void (*)(void)) 类型的异常处理程序地址（BIT0固定为1，表示异常处理程序使用Thumb指令集进行编码） 数组的第二个元素保存的是复位异常处理程序的地址（Reset_Handler） 从理论上说，要想保证APP能正常执行，Bootloader通常要在跳转前“隐藏自己存在过的事实”——需要“对房间进行适度的清理”，并模拟芯片硬件的一些行为——假装芯片复位后是直接从APP开始执行的。 总结来说，Bootloader在跳转到App之前需要做两件事： 1. 清理房间——仿佛Bootloader从未执行过一样 2. 模拟处理器的硬件的一些复位行为——假装芯片从复位开始就直接从APP开始执行 一般来说，做到上述两点，就可以实现App将Bootloader视作黑盒子的效果，从而带来极高的兼容性。甚至在App注入了“跳床（trumpline）”的情况下，实现App既可以独立开发、调试和运行，也可以不经修改的与Bootloader一起工作的奇效。 如何在App中加入“跳床（trumpline）”值得专门再写一篇独立的文章，不是本文所需关注的重点，请允许我暂且略过。 这里，“清理房间”的步骤与Bootloader具体“弄脏了什么”（或者说使用了什么资源）有关；而“模拟处理器硬件的一些复位行为”就较为简单和具体：即，从Bootloader跳转到App前的最后两个步骤为： 从APP的向量表中读取MSP的初始值并以此来初始化MSP寄存器； 从APP的向量表中读取Reset_Handler的值，并跳转到其中去执行——完成从Bootloader到APP的权利交接。 结合前面的例子代码，值得我们关注的部分是： 1. 使用自定义的函数指针类型 pFunction 定义一个局部变量： pFunction Jump_To_Application; 2. 根据向量表的首地址 addr 读取第一个元素——作为MSP的初始值暂时保存在局部变量 StackAddr 中： StackAddr = *(__IO uint32_t*)addr; 3. 根据向量表的首地址 addr 读取第二个元素——将Reset_Handler的首地址保存到局部变量 ResetVector 中： ResetVector = *(__IO uint32_t *)(addr + 4); 4. 设置栈顶指针MSP寄存器： __set_MSP(StackAddr); 5. 通过函数指针完成从Bootloader到App的跳转： Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); 其实，无论具体的代码如何，只要实现步骤与上述类似，就存在一个隐藏较深的漏洞，而漏洞的“触发与否”则完全“看脸”——简单来说： 只要你是按照上述方法来实现从Bootloader到App的跳转的，那么就一定存在问题——而“似乎可以正常工作”就只是你运气较好，或者“由此引发的问题暂时未能引发注意”罢了。 在你试图争辩“老子代码已经量产了也没有什么不妥”之前，我们先来看看漏洞的原理是什么——在知其所以然后，如何评估风险就是你们自己的事情了。 【C语言基础设施是什么】 嵌入式系统的信息安全（Security）建立在基础设施安全（Safety）的基础之上。 由于“确保信息安全的很多机制”本质上是一套建立在“基础设施能够正常工作”这一前提之上的规则和逻辑，因此很多针对信息安全的攻击往往会绕开信息安全的“马奇诺防线”，转而攻击基础设施。芯片数字逻辑的基础设施是时钟源、供电、总线时序、复位时序等等，因此，针对硬件基础设施的攻击通常也就是针对时钟源、电源、总线时序和复位时序的攻击。此时，好奇的小伙伴会产生疑问：固件一般由C语言进行编写，那么C语言所依赖的基础设施又是什么呢？ 对C语言编译器来说，栈的作用是无可替代的： 函数调用 函数间的参数传递 分配局部变量 暂时保存通用寄存器中的内容 …… 可以说，离开了栈C语言寸步难行。因此对很多芯片来说，复位后为了执行用户使用C语言编译的代码，第一个步骤就是要实现栈的初始化。 作为一个有趣的“冷知识”，Cortex-M在宣传中一直强调自己“支持完全使用C语言进行开发”，这让很多人“丈二和尚摸不着头脑”甚至觉得“非常可笑”——因为这年月连51都支持用户使用C语言进行开发了，你这里说的“Cortex-M支持使用C语言进行开发”有什么意义呢？ 其实门道就在这里： 由于Cortex-M处理器会在复位时由硬件完成对C语言基础设施（也就是栈顶指针MSP）的初始化，因此无论是理论上还是实践中，从复位异常处理程序Reset_Handler开始用户就可以完全可以使用C语言进行开发了，而整个启动代码（startup）也可以全然不涉及任何汇编； 由于Cortex-M的向量表是一个完全由 32位整数（uintptr_t）构成的数组——保存的都是地址而非具体代码，可以使用C语言的数据结构直接进行描述——因此也完全不需要汇编语言的介入。 这种从复位一开始就完全不需要汇编介入的友好环境才是Cortex-M声称自己“支持完全使用C语言进行开发”的真实意义和底气。从这一角度出发，只要某个芯片架构复位后必须要通过软件来初始化栈顶指针，就不符合“从出生的那一刻就可以使用C语言”的基本要求。 【C语言编译器的约定】 栈对C语言来说如此重要，以至于编译器一直有一条默认的约定，即： 栈必须完全交由C语言编译器进行管理（或者用户对栈的操作必须符合对应平台所提供的调用规约，比如Arm的AAPCS规约）。 简而言之，如果你“偷偷摸摸”的修改了栈顶指针，C语言编译器是会“假装”完全不知道的，而此时所产生的后果C语言编译器会默认自己完全不用负责。 回头再看这段代码： StackAddr = *(__IO uint32_t*)addr; ResetVector = *(__IO uint32_t *)(addr + 4); __set_MSP(StackAddr); Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); 虽然我们觉得自己“正大光明”的使用了 __set_MSP() 来修改了栈顶指针，但它实际上是一段C语言编译器并不理解其具体功能的在线汇编——在编译器看来，无论是谁提供的 __set_MSP()，只要是在线汇编，这就算是用户代码——是编译器管不到的地带。 /** \brief Set Priority Mask \details Assigns the given value to the Priority Mask Register. \param [in] priMask Priority Mask */__STATIC_FORCEINLINE void __set_PRIMASK(uint32_t priMask){ __ASM volatile ("MSR primask, %0" : : "r" (priMask) : "memory");} 或者说：C语言编译器一般情况下会默认你“无论如何都不会修改栈顶指针”——它不仅管不着，也不想管。 从这点来看，上述代码的确打破了这份约定。即便如此，很多小伙伴会心理倔强的认为：我就这么改了，怎么DE了吧？！ 【问题的分析】 从原理上说，开篇那个典型的Bootloader跳转代码所存在的问题已经昭然若揭： typedef void (*pFunction)(void); void JumpToApp(uint32_t addr){ pFunction Jump_To_Application; __IO uint32_t StackAddr; __IO uint32_t ResetVector; __IO uint32_t JumpMask; JumpMask = ~((MCU_SIZE-1)|0xD000FFFF); if (((*(__IO uint32_t *)addr) & JumpMask ) == 0x20000000) //�ж�SPָ��λ�� { StackAddr = *(__IO uint32_t*)addr; ResetVector = *(__IO uint32_t *)(addr + 4); __set_MSP(StackAddr); Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); }} 我们不妨结合上述代码反汇编的结果进行深入解析： AREA ||i.JumpToApp||, CODE, READONLY, ALIGN=2 JumpToApp PROC000000 b082 SUB sp,sp,#8000002 4909 LDR r1,|L2.40|000004 9100 STR r1,[sp,#0]000006 6802 LDR r2,[r0,#0]000008 400a ANDS r2,r2,r100000a 2101 MOVS r1,#100000c 0749 LSLS r1,r1,#2900000e 428a CMP r2,r1000010 d107 BNE |L2.34|000012 6801 LDR r1,[r0,#0]000014 9100 STR r1,[sp,#0]000016 6840 LDR r0,[r0,#4]000018 f3818808 MSR MSP,r100001c 9001 STR r0,[sp,#4]00001e b002 ADD sp,sp,#8000020 4700 BX r0 |L2.34|000022 b002 ADD sp,sp,#8000024 4770 BX lr ENDP 000026 0000 DCW 0x0000 |L2.40| DCD 0x2fff0000 注意这里，StackAddr、ResetVector是两个局部变量，由编译器在栈中进行分配。汇编指令将SP指针向栈底挪动8个字节就是这个意思： 000000 b082 SUB sp,sp,#8 虽然 JumpMask 也是局部变量，但编译器根据自己判断认为它“命不久矣”，因此直接将它分配到了通用寄存器r2中，并配合r1和sp完成了后续运算。这里： __IO uint32_t JumpMask; JumpMask = ~((MCU_SIZE-1)|0xD000FFFF); if (((*(__IO uint32_t *)addr) & JumpMask ) == 0x20000000) //�ж�SPָ��λ�� { ... } 对应： 000002 4909 LDR r1,|L2.40|000004 9100 STR r1,[sp,#0]000006 6802 LDR r2,[r0,#0]000008 400a ANDS r2,r2,r100000a 2101 MOVS r1,#100000c 0749 LSLS r1,r1,#2900000e 428a CMP r2,r1000010 d107 BNE |L2.34|...|L2.34|000022 b002 ADD sp,sp,#8000024 4770 BX lrENDP 000026 0000 DCW 0x0000|L2.40|DCD 0x2fff0000 考虑到JumpMask的内容与本文无关，不妨暂且跳过。 接下来就是重头戏了： 编译器按照用户的指示读取栈顶指针MSP的初始值，并保存在StackAddr中： StackAddr = *(__IO uint32_t*)addr; 对应的汇编是： 000012 6801 LDR r1,[r0,#0]000014 9100 STR r1,[sp,#0] 根据Arm的AAPCS调用规约，编译器在调用函数时会使用R0~R3来传递前4个符合条件的参数（这里的条件可以简单理解为每个参数的宽度要小于等于32bit）。根据函数原型 void JumpToApp(uint32_t addr); 可知，r0 中保存的就是形参 addr 的值。所以第一句汇编的意思就是：根据 （addr + 0）作为地址读取一个uint32_t型的数据保存到r1中。 第二句汇编中，栈顶指针sp此时实际上指向局部变量 StackAddr，因此其含义就是将通用寄存器r1中的值保存到局部变量 StackAddr 中。 对于局部变量 ResetVector 的读取操作，编译器的处理如出一辙： ResetVector = *(__IO uint32_t *)(addr + 4); 对应： 000016 6840 LDR r0,[r0,#4]00001c 9001 STR r0,[sp,#4] 其实就是从 (addr + 4) 的位置读取 32bit 整数，然后保存到r0里，并随即保存到sp所指向的局部变量 ResetVector 中。到这里，细心地小伙伴会立即跳起来说“不对啊，原文不是这样的！”。是的，这也是最有趣的地方。实际的汇编原文如下： 000016 6840 LDR r0,[r0,#4]000018 f3818808 MSR MSP,r100001c 9001 STR r0,[sp,#4] 作为提醒，它对应的C代码如下： ResetVector = *(__IO uint32_t *)(addr + 4); __set_MSP(StackAddr); 后面的 __set_MSP(StackAddr) 所对应的汇编代码 MSR MSR,r1 居然插入到了ResetVector赋值语句的中间？！ “C语言编译器这么自由的么？” “在我使用sp之前把栈顶指针更新了？！” 先别激动，还记得我们和C语言编译器之间的约定么？C语言编译器默认我们在任何时候都不应该修改栈顶指针。因此在他看来，“你 MSR 指令操作的是r1，关我sp和r0啥事”？“我就算随意更改顺序应该对你一毛钱影响都没有！（因为我不关心、也没法知道用户线汇编语句的具体效果，因此我只关心涉事的通用寄存器是否存在冲突）” 上述“骚操作”的后果是：保存在r0中的Reset_Handler地址值被保存到了新栈中（MSP + 4）的位置。这立即带来两个潜在后果： 由于MSP指向的是栈存储器的末尾（栈是从数值较大的地址向数值较小的地址生长），因此 (MSP+4）实际上已经超出栈的合法范围了。 这一操作与其说是会覆盖栈后续的存储空间，倒不如说风险主要体现在BusFault上——因为相当一部分人习惯将栈放到SRAM的最末尾，而MSP+4直接超出SRAM的有效范围。 我们以为的ResetVector其实已经不在原本C编译器所安排的地址上了。 精彩的还在后面： Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); 对应的翻译是： 00001e b002 ADD sp,sp,#8000020 4700 BX r0 通过前面的分析，我们知道，此时r0中保存的是Reset_Handler的地址，因此 BX r0 能够成功完成从Bootloader到APP的跳转——也许你会松一口气——好像局部变量ResetVector的错位也没引起严重的后果嘛。 看似如此，但真正吓人的是C语言编译器随后对局部变量的释放： 00001e b002 ADD sp,sp,#8 它与一开始局部变量的分配形成呼应： 000000 b082 SUB sp,sp,#8...00001e b002 ADD sp,sp,#8 好借好还，再借不难。但此sp非彼sp了呀！ 这里由于JumpToApp没有加上__NO_RETURN的修饰，因此C编译器并不知道这个函数是有去无回的，因此仍然会像往常一样在函数退出时释放局部变量。 就像刚才分析的那样：由于MSP指向的是栈存储器的末尾（栈是从数值较大的地址向数值较小的地址生长），因此 (MSP+8）实际上已经超出栈存储空间的合法范围了。 考虑到相当一部分人习惯将栈放到SRAM的最末尾，而MSP+8直接超出SRAM的有效范围，即便刚跳转到APP的时候还不会有事，但凡APP用了任何压栈操作，（无论是BusFault还是地址空间绕回）就很有可能产生灾难性的后果。 【宏观分析】 就事论事的讲，单从汇编分析来看，上述代码所产生的风险似乎是可控的，甚至某些人会觉得可以“忽略不计”。但最可怕的也就在这里，原因如下： 从原理上说，将关键信息保存在依赖栈的局部变量中，然后在编译器不知情的情况下替换了栈所在的位置，此后只要产生对相关局部变量的访问就有可能出现“刻舟求剑”的数据错误。这种问题是“系统性的”、“原理性的”。 （此图由GorgonMeducer借助GPT4进行一系列关键词调校、配上台词后获得） 不同编译器、同一编译器的不同版本、同一版本的不同优化选项都有可能对同一段C语言代码产生不同的编译结果，因此哪怕我们经过上述分析得出某一段汇编代码似乎不会产生特别严重的后果，在严谨的工程实践上，这也只能算做是“侥幸”，是埋下了一颗不知道什么时候以什么方式引爆的定时炸弹。 根据用户Bootloader代码在修改 MSP 前后对局部变量的使用情况不同、考虑到用户APP行为的不确定性、由上述缺陷代码所产生的Bootloader与APP之间配合问题的组合多种多样、由于涉及到用户栈顶指针位置的不确定性以及新的栈存储器空间中内容的随机性，最终体现出来的现象也是完全随机的。用人话说就是，经常性的“活见鬼” 【解决方案】 既然我们知道不能对上述缺陷代码抱有侥幸心理，该如何妥善解决呢？第一个思路：既然问题是由栈导致的，那么直接让编译器用通用寄存器来保存关键局部变量不就行了？修改代码为： typedef void (*pFunction)(void); void JumpToApp(uint32_t addr){ pFunction Jump_To_Application; register uint32_t StackAddr; register uint32_t ResetVector; register uint32_t JumpMask; JumpMask = ~((MCU_SIZE-1)|0xD000FFFF); if (((*(__IO uint32_t *)addr) & JumpMask ) == 0x20000000) //�ж�SPָ��λ�� { StackAddr = *(__IO uint32_t*)addr; ResetVector = *(__IO uint32_t *)(addr + 4); __set_MSP(StackAddr); Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); }} 相同编译环境下得出的结果为： AREA ||i.JumpToApp||, CODE, READONLY, ALIGN=2 JumpToApp PROC 000002 6801 LDR r1,[r0,#0]000004 4011 ANDS r1,r1,r2000006 2201 MOVS r2,#1000008 0752 LSLS r2,r2,#2900000a 4291 CMP r1,r200000c d104 BNE |L2.24| 00000e 6801 LDR r1,[r0,#0]000010 6840 LDR r0,[r0,#4]000012 f3818808 MSR MSP,r1 000016 4700 BX r0 |L2.24|000018 4770 BX lr ENDP 00001a 0000 DCW 0x0000 |L2.28| DCD 0x2fff0000 可见，上述汇编中半个 sp 的影子都没看到，问题算是得到了解决。 然而，需要注意的是 register 关键字对编译器来说只是一个“建议”，它听不听你的还不一定。加之上述例子代码本身相当简单，涉及到的局部变量数量有限，因此问题似乎得到了解决。 倘若编译器发现你大量使用 register 关键字导致实际可用的通用寄存器数量入不敷出，大概率还是会用栈来进行过渡的——此时，哪些局部变量用栈，哪些用通用寄存器就完全看编译器的心情了。 进一步的，不同编译器、不同版本、不同优化选项又会带来大量不可控的变数。 因此就算使用 register 修饰关键局部变量的方法可以救一时之疾（“只怪老板催我催得紧，莫怪我走后洪水滔天”），也算不得妥当。 第二个思路：既然问题出在局部变量上，我用静态（或者全局）变量不就可以了？修改源代码为： #include "cmsis_compiler.h" typedef void (*pFunction)(void); __NO_RETURNvoid JumpToApp(uint32_t addr){ pFunction Jump_To_Application; static uint32_t StackAddr; static uint32_t ResetVector; register uint32_t JumpMask; JumpMask = ~((MCU_SIZE-1)|0xD000FFFF); if (((*(__IO uint32_t *)addr) & JumpMask ) == 0x20000000) //�ж�SPָ��λ�� { StackAddr = *(__IO uint32_t*)addr; ResetVector = *(__IO uint32_t *)(addr + 4); __set_MSP(StackAddr); Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); }} 这种方法看似稳如老狗，实际效果可能也不差，但还是存在隐患，因为它“没有完全杜绝编译器会使用栈的情况”，只要我们还会通过 __set_MSP() 在C语言编译器不知道的情况下更新栈顶指针，风险自始至终都是存在的。 对某些连warning都要全数消灭的团队来说，上述方案多半也是不可容忍的。 第三个思路：完全用汇编来处理从Bootloader到App的最后步骤。对此我只想说：稳定可靠，正解。 只不过需要注意的是：这里整个函数都需要用纯汇编打造，而不只是在C函数内容使用在线汇编。 原因很简单：既然我们已经下定决心要追求极端确定性，就不应该使用线汇编这种与C语言存在某些“暧昧交互”的方式——因为它仍然会引入一些意想不到的不确定性。 本着一不做二不休的态度，完全使用汇编代码来编写跳转代码才是万全之策。 【说在后面的话】 在使用栈的情况下，on-fly 的修改栈顶指针就好比在飞行途中更换引擎——不是不行，只是要求有亿点点高。 我在微信群中帮读者分析各类Bootloader的见鬼故障时，经常在大费周章的一通分析和调试后，发现问题的罪魁祸首就是跳转代码。可怕的是，几乎每个故障的具体现象都各不相同，表现出的随机性也常常让人怀疑是不是硬件本身存在问题，亦或是产品工作现场的电磁环境较为恶劣。最要命的当数那种“偶尔出现”而复现条件颇为玄学的情形，甚至在办公室环境下完全无法重现的也大有人在。同样的问题出的多了，我几乎在每次帮人调试Bootloader时都会习惯性的先要求检查跳转代码——虽然不会每次都能猜个正着，但也有个恐怖的十之七八。这也许是某种幸存者偏差吧——毕竟大部分普通问题大家自己总能解决，到我这里的多半就是“驱鬼”了。见得多了，我突然发现，出问题的代码大多使用函数指针来实现跳转——而用局部变量来保存函数指针又成了大家自然而然的选择。加之此前很多文章都曾大规模科普上述技巧，甚至是直接包含一些存在缺陷的Bootloader范例代码，实际受影响的范围真是“细思恐极”。特此撰文，为您解惑。
单片机编程软件数量不多，Keil和IAR为当前主流的单片机编程软件。对于每门单片机编程软件的学习，总需耗费一定必要的时间。为最大化减少大家对单片机编程软件学习时间的投入，本文特地带来IAR单片机编程软件相关教程...
好的单片机编程软件受到众多开发人员青睐，而对单片机编程软件了解较多的朋友都知道，目前市场上主要流通的单片机编程软件为Keil和IAR。本文中，主要为大家讲解IAR单片机编程软件的基础教程。如果你对IAR存在一定兴...
本文探讨自动驾驶中的DCU、MCU和MPU在电子电气架构中的作用，比较了分布式与集中式架构的优势，以及ADAS系统从L0-L2+的发展历程。
扫码关注面包板社区
