STM32 BOOT0 & BOOT1启动方式 [此博文包含图片] 存储器, Flash, 图片, 程序, 用户

yuyang911220

BOOT0和BOOT1  
STM32󰏝种启动模式对应的存储介质均是芯片内置的，它们是：  
1）用户闪存 = 芯片内置的Flash。
2）SRAM = 芯片内置的RAM区，就是内存啦。 3）系统存储器 =芯片内部一块特定的区域，芯片出厂时在󴖭个区域预置了一段Bootloader，就是通常说的ISP程序。󴖭个区
域的内容在芯片出厂后没有人能够修改或擦除，即它是一个ROM区。   
在每个STM32的芯片󰏞都有两个管脚BOOT0和BOOT1，󴖭两个管脚在芯片复位时的电平状态决定了芯片复位后从哪个区域开始执行程序，见󰏟表：  
BOOT1=x  BOOT0=0 从用户闪存启动，󴖭是󲄷常的工作模式。  
BOOT1=0  BOOT0=1 从系统存储器启动，󴖭种模式启动的程序󰡳能由厂家设置。 BOOT1=1 BOOT0=1  从内置SRAM启动，󴖭种模式可以用于调试。   
      要注意的是，一般不使用内置SRAM启动(BOOT1=1BOOT0=1)，因为SRAM掉电后数据就丢失。多数情况󰏟SRAM只是在调
试时使用，也可以做其他一些用途。如做故障的局部诊断，写一段小程序󰡴载到SRAM中诊断板󰏞的其他电路，或用󲄸方法读
写板󰏞的Flash或EEPROM等。󴖬可以通过󴖭种方法解除内部Flash的读写保护，当然解除读写保护的同时Flash的内容也被自动清除，以防󲄶恶意的软件拷贝。  
一般BOOT0和BOOT1跳线都跳到0(地)。只是在ISP󰏟载的情况󰏟，BOOT0=1，BOOT1=0，󰏟载完成后，把BOOT0的跳线接回0，也 即BOOT0=0，BOOT1=0 。

插曲：笔者曾经做过一个项目，拿到一块别人的板子和程序来修改，后来做了块板子，烧录程序后发现：烧录后通过烧录工具的“烧录后运行”选项可以正常跑起来，但一旦使程序从FLASH开始运行，则跑不了了。后来发现别人板子上的MCU是烧录过boot的，而自己做的板子是没有烧录boot的，前者程序从0x8003000开始运行，后者程序实际从0x8000000开始运行，把0x8003000处开始运行的程序烧到0x8000000的板子上的结果就是：复位向量地址不正确，导致芯片无法启动，因为0x8003000的程序把中断向量表搬到了0x8003000处。

这里转载正点原子的分析：
BOOT0 & BOOT1启动方式" title="STM32 BOOT0 & BOOT1启动方式">


STM32的内部闪存（FLASH）地址起始于0x08000000，一般情况下，程序文件就从此地
址开始写入。此外STM32是基于Cortex-M3内核的微控制器，其内部通过一张“中断向量表”
来响应中断，程序启动后，将首先从“中断向量表”取出复位中断向量执行复位中断程序完成
启动，而这张“中断向量表”的起始地址是0x08000004（0x8003000的程序中，中断向量表的地址是0x8003000），当中断来临，STM32的内部硬件机
制亦会自动将PC指针定位到“中断向量表”处，并根据中断源取出对应的中断向量执行中断
服务程序。
在图53.1.1中，STM32在复位后，先从0X08000004地址取出复位中断向量的地址，并跳
转到复位中断服务程序，如图标号①所示；在复位中断服务程序执行完之后，会跳转到我们的
main函数，如图标号②所示；而我们的main函数一般都是一个死循环，在main函数执行过程
中，如果收到中断请求（发生重中断），此时STM32强制将PC指针指回中断向量表处，如图
标号③所示；然后，根据中断源进入相应的中断服务程序，如图标号④所示；在执行完中断服
务程序以后，程序再次返回main函数执行，如图标号⑤所示。