STM32启动流程深度解析：从复位向量到uC/OS-II首个任务

1. 这不是“烧录成功”就完事了为什么你写的STM32程序总在启动时莫名卡死你有没有遇到过这样的情况Keil编译通过、ST-Link能连上、hex文件也烧进Flash了但一按复位键LED不亮、串口没输出、调试器连不上——程序就像被按了暂停键永远停在某个看不见的地方更诡异的是有时候换一块板子、换个晶振、甚至只是把开发板从USB插座拔出来再插回去问题就消失了。这不是玄学是启动流程里某个环节出了偏差。我第一次在客户现场遇到这个问题时手头是一块刚贴片回来的定制板用的是STM32F103C8T6跑uC/OS-II。系统在main()函数第一行printf(start)都没执行J-Link连接后直接报“Target not halted”连调试断点都打不进去。当时以为是Boot引脚接错、电源滤波不良、或者晶振不起振——查了三天换了三颗晶振、加了五颗去耦电容、重焊了所有电源引脚最后发现罪魁祸首是启动文件里一个被注释掉的.section .isr_vector段地址偏移量写错了。它没导致编译失败却让复位向量表被加载到了错误的Flash位置CPU一上电就跳到一片空白内存里执行自然死得无声无息。这就是“从复位向量到第一个任务”这个标题背后的真实分量它不是教科书里一句“CPU复位后从0x00000000取PC值”的抽象描述而是你每天调试时真正踩过的坑、烧坏的芯片、熬过的夜。它涉及硬件上电时序、Flash控制器初始化、SRAM内容清零、中断向量重映射、堆栈指针设置、C运行时环境构建、RTOS内核初始化……每一个环节都像多米诺骨牌前一块倒下后面全乱套。尤其当你用uC/OS-II这类需要手动配置任务堆栈、管理中断嵌套深度的实时系统时启动阶段哪怕一个字节的栈顶地址算错都会导致任务切换瞬间崩溃而这种崩溃往往没有日志、没有报错、只有沉默。这篇文章要讲的就是把这块“黑箱”彻底打开。不讲泛泛而谈的ARM Cortex-M3架构手册只讲你在Keil工程里实际改的那几行汇编、在startup_stm32f10x_md.s里删掉又加回去的那段代码、在system_stm32f10x.c里调用的SetSysClockTo72()函数到底干了什么。我会带着你从按下电源键那一刻开始逐行跟踪每一条指令的执行路径直到uC/OS-II的第一个任务AppTaskStart()被调度器推入运行态。过程中你会明白为什么__main标号之后必须紧跟__rt_entry为什么SystemInit()必须在C库初始化之前调用为什么uC/OS-II的OSStartHighRdy()不能放在main()末尾以及当你的flash download failed错误反复出现时真正该检查的不是ST-Link驱动而是Flash编程算法里那个被忽略的FLASH_OB_WRP寄存器状态。如果你正在做基于STM32的毕业设计、工业控制模块或智能硬件产品尤其是涉及USB设备、超声波测距、EtherCAT主站这类对时序和稳定性要求极高的场景那么启动流程的每一个细节都直接决定你的项目是按时交付还是卡在量产前最后一轮测试里反复返工。这不是理论探讨是实打实的工程底线。2. 启动全流程四阶拆解硬件上电→向量跳转→C环境构建→RTOS接管整个启动过程绝非线性流水线而是一个层层依赖、环环相扣的精密协作。我把STM32F103以Cortex-M3内核为例的启动划分为四个不可跳过的阶段每个阶段都有其明确的输入、输出和失败特征。理解这四个阶段你就掌握了定位启动问题的黄金地图。2.1 阶段一硬件上电与复位电路响应0ms ~ 10ms这是所有软件逻辑的物理起点。STM32的复位源有多种上电复位POR、掉电复位PDR、外部复位引脚NRST、看门狗复位WWDG/ IWDG、软件复位SYSRESETREQ。但无论哪种最终都归结为一个信号复位引脚NRST被拉低至少20μs然后释放。这个动作触发芯片内部的复位逻辑将所有寄存器恢复默认值PC指针强制指向复位向量地址。关键细节在于“复位向量地址”的确定方式。Cortex-M3规定复位向量位于向量表的第1个条目索引0其值为复位处理程序的入口地址。而向量表的起始地址并非固定在0x00000000而是由BOOT引脚状态决定BOOT[1:0] 引脚状态向量表起始地址典型用途0 0主Flash存储器0x08000000正常运行模式程序从内部Flash启动0 1系统存储器0x1FFFF000从内置Bootloader启动用于ISP升级1 0内置SRAM0x20000000调试模式程序加载到RAM中运行提示很多初学者误以为BOOT0/BOOT1接VDD或GND只是“选择启动方式”其实它直接决定了CPU取指的物理地址空间。如果BOOT01、BOOT10但你的程序烧在Flash里CPU就会从SRAM地址0x20000000开始找向量表——而那里是空的结果就是PC跳到随机地址执行表现为完全无响应。实操中这个阶段最容易出问题的不是代码而是硬件电源爬升时间不足STM32F103要求VDD在10ms内从0V升至2.0V以上。若使用LDO稳压器输出电容过大如470μF或输入电源内阻过高会导致POR信号延迟释放CPU在电源未稳定时就开始取指读取Flash数据出错。NRST引脚退耦不良标准设计是在NRST与VDD之间接100nF电容在NRST与GND之间接10kΩ电阻。若电容值过小10nF无法滤除高频干扰可能导致误复位若电阻过大100kΩ则复位释放时间过长影响启动速度。晶振起振失败HSI内部8MHz RC是复位后的默认时钟源但多数工程会立即切换到HSE外部晶振。若HSE晶振负载电容选错如8MHz晶振配22pF电容而手册推荐12pF或晶振本身质量差会导致RCC_CR寄存器中HSERDY标志位永远不置位后续所有依赖HSE的外设如USB、ADC均无法工作。我曾在一个基于STM32F103的鱼缸控制系统中遇到类似问题设备在实验室正常但装入鱼缸金属外壳后频繁重启。最终发现是金属外壳形成电磁屏蔽导致24MHz HSE晶振辐射被抑制起振失败。解决方案不是换晶振而是在晶振旁并联一个10pF微调电容微调谐振点。2.2 阶段二向量表跳转与启动代码执行10ms ~ 50ms一旦NRST释放CPU从向量表首地址通常为0x08000000读取复位向量值即Reset_Handler的地址然后跳转执行。这个Reset_Handler就是启动文件如startup_stm32f10x_md.s里的汇编入口。这里必须厘清一个常见误解Reset_Handler不是C语言的main()函数而是整个C运行时环境的奠基者。它的核心任务有三项初始化堆栈指针SP从向量表第二个条目索引1读取初始SP值。这个值通常定义在启动文件开头的.stack段例如_estack EQU 0x20005000对应SRAM末尾地址。若此处地址计算错误如SRAM大小写成48KB而非20KBSP就会指向非法内存后续任何局部变量操作都会引发HardFault。拷贝初始化数据段.dataC语言中全局/静态变量的初始值如int a 5;存储在Flash的.data段但运行时需加载到SRAM中。Reset_Handler会执行一段循环将Flash中.data的原始值复制到SRAM对应地址。清零未初始化数据段.bss全局/静态变量中未显式初始化的部分如int b;必须为0这部分内存区域.bss在SRAM中由启动代码用MOVSTR指令批量清零。注意.data拷贝和.bss清零的地址范围由链接脚本如stm32f10x_md.ld严格定义。若链接脚本中_sidata.data在Flash中的起始地址与_sdata.data在SRAM中的起始地址不匹配就会把错误的数据拷贝到错误的位置。例如.data在Flash中占0x08002000~0x080020FF但链接脚本误写为0x08002000~0x080021FF多拷贝的1个字节可能覆盖紧邻的.bss区首地址导致某个关键全局变量被意外置0。启动代码执行完毕后会调用C库的__main函数。这不是你写的main()而是ARM C库提供的运行时初始化入口。它负责设置浮点单元FPU状态若启用初始化C标准库I/O缓冲区如stdout调用全局对象构造函数C项目最终跳转到用户定义的main()函数这个阶段失败的典型现象是程序能进入main()但printf无输出、全局变量值异常、数组访问越界。根源几乎都在启动文件或链接脚本的地址配置上。2.3 阶段三C运行时环境构建与系统时钟配置50ms ~ 200msmain()函数是C世界的起点但此时系统仍处于“裸机”状态时钟未配置、外设未使能、中断未开启。main()的第一件事通常是调用SystemInit()——这个函数定义在system_stm32f10x.c中它完成了Cortex-M3芯片最核心的初始化。SystemInit()的核心逻辑是配置RCC复位与时钟控制寄存器建立稳定的系统时钟树。以STM32F103为例其典型配置路径为使能HSE设置RCC_CR寄存器的HSEON位等待HSERDY标志置位。配置PLL将HSE8MHz作为PLL输入通过RCC_CFGR的PLLMUL字段设置倍频系数如×9得到72MHz。选择PLL作为系统时钟源设置RCC_CFGR的SW字段为01PLLCLK。配置AHB/APB总线分频设置HPREAHB预分频、PPRE1/2APB1/APB2预分频确保各总线时钟不超过器件最大频率如APB1≤36MHz。实操心得SystemInit()必须在任何外设初始化之前调用。我曾在一个USB虚拟串口项目中把USART1_Init()放在SystemInit()之前结果发现串口波特率始终不对。原因是USARTDIV寄存器的计算公式为DIV (CLK / (16 * BAUD))而CLK在此时仍是默认的HSI8MHz而非配置后的72MHz导致实际波特率偏差达900%。正确顺序是SystemInit()→RCC_Enable()→GPIO_Init()→USART_Init()。完成时钟配置后紧接着是外设时钟使能。STM32采用门控时钟设计每个外设的时钟默认关闭必须显式使能。例如要使用GPIOA需执行RCC_APB2PeriphClockCmd(RCC_APB2PERIPH_GPIOA, ENABLE)要使用USART1需执行RCC_APB2PeriphClockCmd(RCC_APB2PERIPH_USART1, ENABLE)。漏掉任何一个对应外设寄存器读写将无效。此阶段还涉及中断向量表重映射。Cortex-M3默认向量表在0x00000000但STM32的Flash起始地址是0x08000000。因此必须通过SCB-VTOR寄存器将向量表基址重映射到Flash首地址SCB-VTOR FLASH_BASE | VECT_TAB_OFFSET;其中VECT_TAB_OFFSET是向量表在Flash内的偏移量通常为0。若此步缺失即使你写了NVIC_Init()中断服务程序也无法被正确调用。2.4 阶段四RTOS内核初始化与首个任务调度200ms ~ 500ms当main()函数完成所有硬件初始化后控制权交给RTOS。以uC/OS-II为例其启动流程有严格顺序调用OSInit()初始化内核内部数据结构如就绪表、事件控制块、消息队列等。此函数必须在创建任何任务前调用。创建应用任务使用OSTaskCreate()创建多个任务。每个任务需指定任务函数指针、参数、堆栈起始地址、堆栈大小、优先级。堆栈大小是极易出错的点uC/OS-II的堆栈是向下增长的若分配过小如仅256字节任务在执行printf或调用复杂函数时会溢出覆盖相邻内存导致不可预测崩溃。启动调度器OSStart()这是启动流程的终点。它首先禁用所有中断然后调用OSStartHighRdy()。该函数执行最后两步关键操作将最高优先级就绪任务的堆栈指针SP加载到CPU的SP寄存器执行BX LR指令将PC指向该任务的入口地址正式开始任务执行。关键区别OSStart()不是返回到main()而是永久交出CPU控制权。因此OSStart()之后的任何代码包括while(1)永远不会执行。这也是为什么uC/OS-II要求main()函数在调用OSStart()后不返回。至此“从复位向量到第一个任务”的全流程闭环完成。CPU不再执行固定的启动代码而是根据RTOS调度策略在多个并发任务间动态切换。第一个被调度的任务就是你通过OSTaskCreate()创建的、优先级最高的那个——它才是真正意义上的“第一个任务”。3. 核心细节深挖向量表、启动文件、链接脚本与uC/OS-II的协同机制启动流程的可靠性不取决于某一行炫酷的C代码而取决于那些看似枯燥的底层配置向量表的布局、启动文件的汇编指令、链接脚本的内存映射、以及RTOS内核与硬件的握手协议。这些细节共同构成了系统稳定运行的基石。3.1 向量表不只是地址列表而是CPU的“导航地图”Cortex-M3的向量表是一个包含16个32位字的数组每个字代表一个异常或中断的入口地址。STM32F103的向量表结构如下地址偏移量从0x00开始偏移量名称描述典型值Flash启动0x00Initial Stack Pointer (ISP)复位时的初始SP值0x20005000SRAM末尾0x04Reset Handler复位中断服务程序地址0x08000141Reset_Handler入口0x08NMI Handler不可屏蔽中断0x08000145NMI_Handler0x0CHardFault Handler硬件故障中断0x08000149HardFault_Handler............0x3CSysTick Handler系统滴答定时器0x0800018DSysTick_Handler向量表的物理位置由SCB-VTOR寄存器决定。在SystemInit()之后我们通常将其设为FLASH_BASE0x08000000。这意味着CPU在发生中断时会从0x08000000 中断号*4处读取服务程序地址。为什么向量表必须严格对齐Cortex-M3要求向量表起始地址必须是256字节的整数倍即最低8位为0。这是因为VTOR寄存器的低8位被保留实际生效的地址是VTOR 0xFFFFFE00。如果向量表放在0x08000004VTOR会被自动截断为0x08000000导致向量表错位所有中断都无法正确响应。在uC/OS-II中向量表的完整性至关重要。RTOS内核依赖PendSV挂起系统调用和SysTick系统节拍两个异常来实现任务切换。PendSV的向量地址必须正确指向uC/OS-II提供的OS_CPU_PendSVHandler()否则OSCtxSw()任务上下文切换将无法触发SysTick的向量地址必须指向OS_CPU_SysTickHandler()否则OSTimeDly()等时间相关函数将失效。3.2 启动文件汇编代码里的“生命之源”以Keil MDK下的startup_stm32f10x_md.s为例其核心部分如下; 定义堆栈大小 Stack_Size EQU 0x00000400 ; 堆栈段从高地址向下增长 AREA STACK, NOINIT, READWRITE, ALIGN3 Stack_Mem SPACE Stack_Size __initial_sp ; 栈顶地址符号供链接器使用 ; 定义堆大小可选 Heap_Size EQU 0x00000200 AREA HEAP, NOINIT, READWRITE, ALIGN3 __heap_base Heap_Mem SPACE Heap_Size __heap_limit ; 向量表 AREA RESET, DATA, READONLY ; 复位向量必须是第一个 __Vectors DCD __initial_sp ; 栈顶 DCD Reset_Handler ; 复位处理程序 DCD NMI_Handler ; NMI处理程序 DCD HardFault_Handler ; 硬故障处理程序 ; ... 其他向量这段代码定义了三个关键内存段STACK段存放运行时堆栈__initial_sp是其起始地址即栈顶。链接脚本会将此符号赋给SP寄存器。HEAP段存放动态内存分配mallocuC/OS-II通常不使用故常设为0。RESET段即向量表DCD伪指令生成32位字常量。最关键的汇编指令是Reset_Handler的主体Reset_Handler PROC EXPORT Reset_Handler [WEAK] IMPORT __main IMPORT SystemInit LDR R0, SystemInit BLX R0 ; 调用SystemInit() LDR R0, __main BX R0 ; 跳转到C库__main ENDP这里BLX R0是带链接的跳转它会将返回地址存入LR寄存器。当__main执行完毕最终BX LR会回到Reset_Handler的下一条指令——但这条指令不存在因为__main会直接跳转到main()。所以Reset_Handler本身并不返回。3.3 链接脚本内存布局的“宪法文件”链接脚本如stm32f10x_md.ld定义了程序在Flash和SRAM中的精确布局。一个典型的配置如下MEMORY { FLASH (rx) : ORIGIN 0x08000000, LENGTH 64K RAM (rwx) : ORIGIN 0x20000000, LENGTH 20K } SECTIONS { .isr_vector : { . ALIGN(4); _isr_vector_start .; KEEP(*(.isr_vector)) . ALIGN(4); _isr_vector_end .; } FLASH .text : { . ALIGN(4); *(.text) *(.rodata) . ALIGN(4); } FLASH .data : { . ALIGN(4); _data_start .; *(.data) _data_end .; } RAM AT FLASH .bss : { . ALIGN(4); _bss_start .; *(.bss) *(COMMON) _bss_end .; } RAM }这个脚本的关键点在于.isr_vector段必须位于Flash起始地址KEEP(*(.isr_vector))确保向量表被强制放置在.text段之前且ORIGIN 0x08000000保证其物理地址正确。.data段的加载地址AT与运行地址分离 RAM AT FLASH表示.data的内容存储在Flash中但运行时需加载到RAM中。链接器会生成两个符号_sidataFlash中.data的起始地址和_sdataRAM中.data的起始地址启动代码正是用这两个符号进行拷贝。.bss段只需在RAM中清零它没有对应的Flash存储因此链接脚本中不指定AT属性。若链接脚本中.isr_vector段被错误地放在.text之后或ORIGIN地址写错向量表就会偏离0x08000000导致复位后CPU跳转到错误地址。3.4 uC/OS-II与Cortex-M3的深度绑定寄存器上下文与任务切换uC/OS-II的任务切换本质上是CPU寄存器状态的保存与恢复。Cortex-M3提供了一个精妙的硬件支持PendSV异常。当RTOS需要切换任务时它不直接修改SP而是触发PendSV异常。CPU在进入PendSV服务程序前会自动将当前任务的xPSR,PC,LR,R12,R3-R0共8个寄存器压入当前任务的堆栈称为“自动压栈”。PendSV服务程序OS_CPU_PendSVHandler则负责保存剩余寄存器R11-R4到当前任务堆栈调用OSPrioCur OSPrioHighRdy更新当前优先级从最高优先级就绪任务的堆栈中弹出R4-R11执行BX LR触发CPU的“自动出栈”将R0-R3,R12,LR,PC,xPSR恢复。这个过程之所以高效是因为PendSV的优先级被设置为最低NVIC_SetPriority(PendSV_IRQn, 0xFF)确保它不会打断任何用户任务或中断服务程序只在所有更高优先级的处理完成后才执行。OSStartHighRdy()的实现正是利用了这一机制void OSStartHighRdy (void) { // 关闭中断 OS_CPU_SR_Save(); // 获取最高优先级就绪任务的堆栈指针 OSPrioCur OSPrioHighRdy; OSTCBCur OSTCBHighRdy; // 加载SP寄存器 SP OSTCBHighRdy-OSTCBStkPtr; // 触发PendSV开始任务执行 OS_CPU_PendSVHandler(); }注意OS_CPU_PendSVHandler()在此处并非被“调用”而是通过BX指令模拟了一次PendSV异常的进入。这使得CPU的自动压栈/出栈机制被激活从而无缝地将CPU上下文切换到新任务。4. 实操全流程从新建Keil工程到uC/OS-II第一个任务点亮LED现在让我们把前面所有理论落实到一个可运行的Keil MDK工程中。目标创建一个基于STM32F103C8T6的工程使用uC/OS-II v2.91让AppTaskStart()任务每500ms翻转一次PA0引脚控制LED。这个过程将覆盖所有关键步骤并标注易错点。4.1 工程创建与基础配置Keil MDK v5.37新建工程Project→New uVision Project...选择芯片STM32F103C8。添加启动文件右键Source Group 1→Add Existing Files to Group...添加startup_stm32f10x_md.s位于Keil\ARM\Startup\ST\STM32F10x。添加标准外设库将STM32F10x_StdPeriph_Lib_V3.5.0文件夹复制到工程目录。在Options for Target→C/C→Include Paths中添加.\STM32F10x_StdPeriph_Lib_V3.5.0\Library\INC .\STM32F10x_StdPeriph_Lib_V3.5.0\Library\SRC添加uC/OS-II源码将uCOS-II\Source和uCOS-II\Ports\ARM-Cortex-M3\Generic\RealView文件夹复制到工程目录。在Include Paths中添加.\uCOS-II\Source .\uCOS-II\Ports\ARM-Cortex-M3\Generic\RealView注意uC/OS-II的移植层os_cpu.h,os_cpu_c.c,os_cpu_a.asm必须与你的编译器ARMCC和CPUCortex-M3严格匹配。RealView目录下的文件专为ARMCC设计若你用GCC则需用GCC目录下的文件。4.2 关键文件修改与配置第一步修改system_stm32f10x.c找到SetSysClockTo72()函数确保其内部调用了正确的RCC配置序列。重点检查RCC_DeInit()是否被调用复位RCC寄存器RCC_HSEConfig(RCC_HSE_ON)后是否有while (RCC_GetFlagStatus(RCC_FLAG_HSERDY) RESET)等待RCC_PLLConfig(RCC_PLLSource_HSE_Div1, RCC_PLLMul_9)是否正确HSE/1 × 9 72MHzRCC_SYSCLKConfig(RCC_SYSCLKSource_PLLCLK)是否在PLL就绪后调用。第二步配置os_cfg.h这是uC/OS-II的“开关清单”。必须修改的关键项#define OS_MAX_TASKS 10 // 最大任务数必须≥你创建的任务数 #define OS_TICK_RATE_HZ 1000 // 系统节拍频率1000Hz 1ms #define OS_TASK_IDLE_STK_SIZE 128 // 空闲任务堆栈大小最小128字节 #define OS_TASK_STAT_STK_SIZE 128 // 统计任务堆栈大小 #define OS_TASK_TMR_STK_SIZE 128 // 定时器任务堆栈大小实操心得OS_MAX_TASKS必须精确。若设为5但你创建了6个任务OSTaskCreate()会返回OS_ERR_TASK_CREATE_ISR错误且无任何提示。建议初学时设为10留足余量。第三步编写main.c#include includes.h // 任务堆栈定义 OS_STK AppTaskStartStk[APP_TASK_START_STK_SIZE]; // 任务函数声明 void AppTaskStart(void *pdata); int main(void) { // 1. 硬件初始化 RCC_DeInit(); // 复位RCC RCC_HSEConfig(RCC_HSE_ON); // 使能HSE while (RCC_GetFlagStatus(RCC_FLAG_HSERDY) RESET); // 等待HSE就绪 RCC_SYSCLKConfig(RCC_SYSCLKSource_HSE); // 临时用HSE作为SYSCLK RCC_HCLKConfig(RCC_SYSCLK_Div1); // AHB SYSCLK RCC_PCLK2Config(RCC_HCLK_Div1); // APB2 AHB RCC_PCLK1Config(RCC_HCLK_Div2); // APB1 AHB/2 // 2. GPIO初始化 RCC_APB2PeriphClockCmd(RCC_APB2PERIPH_GPIOA, ENABLE); GPIO_InitTypeDef GPIO_InitStructure; GPIO_InitStructure.GPIO_Pin GPIO_Pin_0; GPIO_InitStructure.GPIO_Mode GPIO_Mode_Out_PP; GPIO_InitStructure.GPIO_Speed GPIO_Speed_50MHz; GPIO_Init(GPIOA, GPIO_InitStructure); // 3. uC/OS-II初始化 OSInit(); // 4. 创建起始任务 OSTaskCreate(AppTaskStart, (void *)0, AppTaskStartStk[APP_TASK_START_STK_SIZE - 1], 1); // 5. 启动RTOS OSStart(); // 永远不会执行到这里 return 0; } void AppTaskStart(void *pdata) { (void)pdata; while (1) { GPIO_WriteBit(GPIOA, GPIO_Pin_0, Bit_SET); OSTimeDlyHMSM(0, 0, 0, 500); // 延时500ms GPIO_WriteBit(GPIOA, GPIO_Pin_0, Bit_RESET); OSTimeDlyHMSM(0, 0, 0, 500); } }第四步配置链接脚本Keil默认使用STM32F10x_FLASH.lnp但需确认其内容与芯片匹配。打开Options for Target→Linker→Use Memory Layout from Target Dialog勾选Use Memory Layout from Target Dialog并确保IRAM1和IROM1的起始地址与大小正确IROM1: Start0x08000000, Size0x00010000 (64KB)IRAM1: Start0x20000000, Size0x00005000 (20KB)4.3 编译、下载与调试排查常见错误编译阶段常见错误Error: #20: identifier OS_STK is undefined未包含includes.h或os_cfg.h路径未添加。Error: #137: expression must be a modifiable lvalue在OSTaskCreate()中堆栈指针参数写成了AppTaskStartStk[0]栈底正确应为AppTaskStartStk[APP_TASK_START_STK_SIZE - 1]栈顶。下载阶段常见错误Flash Download failed - Cortex-M3这是最经典的报错。原因及排查顺序检查ST-Link连接设备管理器中是否识别为STMicroelectronics STLink dongle若显示黄色感叹号重装ST-Link驱动。检查BOOT引脚确保BOOT00, BOOT10从Flash启动。检查Flash算法Options for Target→Utilities→Settings→Flash Download选择正确的Flash编程算法如STM32F1xx Flash。若算法版本不匹配如用F103算法烧F105会失败。检查Flash保护使用ST-Link Utility软件连接芯片查看Option Bytes页签。若Read out Protection (ROP)为Level