正文

不得不提的启动方式

STM32支持三种启动方式 
1. FLASH启动 
2. SRAM启动 
3. 系统存储器启动

这三种启动顺序决定了上电后第一条指令的位置。如果你选择FLASH启动，则上电复位后PC指针指向第一条指令位置——0x08000000，如果你选择SRAM启动，则上电复位后PC指针指向第一条指令位置——0X20000000，若你选择系统存储器启动，则上电复位后PC指针指向第一条指令位置——0X1FFF0000。 
为什么会这样呢？接下来我们分析一下STM32F4的存储区地址结构。 

上图摘自《Cortex-M3与M4权威指南》。从这里我们可以看出M4内核支持4GB的存储空间，从0X00000000-0X1FFFFFFF共512MB的空间是Code区，0x20000000-0x3FFFFFFF共512MB的空间是SRAM，其他的我们暂且不分析。我们再来看看《STM32F4xx Reference manual 》中 关于F4系列的物理内存映射

从上面的物理内存映射图我们可以看出：

0x08000000-0x080FFFFF: FLASH 
0x1FFF0000-0x1FFF77FF: System memory 
0x20000000-0x2001FFFF: SRAM

其中FLASH大小为1MB, SRAM大小为12KB, System memory大小为30KB。

在这里解释三个问题：

1. 《Cortex-M3&M4权威指南》中讲到“系统上电复位后，从0x00000000处加载第一条指令…..”为什么上面提到的三种启动方式都是从非0x00000000加载第一条的呢？-这就是“地址映射”的作用了。我们通过boot0&1引脚的配置，可以选择不同的启动方式，同时将flash或sram的基地址映射到启动空间0x00000000处，这样，加载的第一条指令位置便是我们相应的启动方式对应的存储设备的地址了。

2. 三种启动方式有何区别？显然，第一点不同就是地址空间不同，导致了三种启动方式启动时代码加载空间随之改变；此外System memory是个真正的ROM，里面固化了厂家出厂时的BootLoader代码，不可重写。FLASH和SRAM则可自己重写程序完成启动，但是由于芯片特性原因，两者的用途也不一样。FLASH就是我们常说的闪存，具有”掉电不失性”，烧写代码后，代码不会因为掉电而丢失，下次上电启动时仍然可以正常启动，为常见的启动方式，但是缺点是运行速度较慢；SRAM是“静态随机存储器”，具有“掉电易失性”，属于RAM的一种，那么显然我们不可能将代码长保存到SRAM中，因为下次上电后仍旧没有代码。这种启动方式常用于程序调试，即上电后下载代码，运行，进行调试，运行速度比FLASH快。

3. 为什么FLASH不是RAM也可以运行程序？FLASH分为两种，一种是Nor FLASH, 一种是Nand FLASH。这两者区别就不一一赘述，网上资料很多，在这里我们只需要明确：Nor FLASH 支持片内执行，Nand FLASH不支持片内执行，而我们使用的STM32F4系列芯片内置的1MB的FLASH属于Nor FLASH，所以便有从FLASH启动这一说法。

解释完这三个问题，我们便可以谈谈IAP了

关于IAP

IAP全称为 In Application Programing，即“应用内编程”，按照我个人的理解就是：我们通常下载到开发板上的程序其实是两部分——BOOT+APP， BOOT代码负责必要的堆栈，中断向量表等初始化，而APP才是我们真正需要的功能代码，而STM32已经有.s启动文件支持，所以我们无需关注BOOT部分，只需完成相应的功能代码即可，通常无论你代码内有多少功能，但你下载的文件只有一个，即BOOT+APP，且只能通过特定的方式写入到FLASH或者SRAM内运行。而应用内编程，则打破了这个规则，原则上只要存储空间无限大，我们就可以使用IAP可以下载到FLASH内部无限多个应用程序。

下面我简单的画一下两者的运行机理： 

应该不难看出，其实所谓的IAP，就是先写一个APP作为伪BOOT，在系统初始化完成之后，引导系统加载真正的APP程序，使之运行，完成真正的APP程序的功能。这样我们就可以下载多个APP在不同空间内，只要让引导程序做出相应的跳转工作，便可以实现运行对应APP功能。

讲到这里，我们先来思考下面四个问题：

1. 伪BOOT完成了哪些工作？

2. APP程序是如何下载到开发板上去的，对空间有特殊要求吗？

3. 伪BOOT到APP之间的跳转如何完成？

4. APP程序需要具有哪些功能？

下来我们就来分析分析

刚才已经提到过，伪BOOT其实就是我们平时写的APP程序，为什么我要叫他伪BOOT呢？因为他并不是一个真正的BOOT程序，他也是一个BOOT+APP程序，只不过这个程序在IAP编程中完成的工作很像一个BOOT程序，所以我起了个名字叫做伪BOOT。 
我们先来看看一般BOOT程序完成的工作：单片机上电复位之后，程序指针PC指向0x00000000(映射到FLASH的0x08000000或者SRAM的0x20000000处)，这里存放的是用户堆栈栈顶地址，获取到栈顶指针后，程序指针向后偏移4个字节，指向0x00000004（映射到FLASH的0X80000004或者SRAM的0X20000004）,这里存放的是系统中断复位的指针，然后程序跳转到Reset_Handler执行SystemInit（系统复位）工作，在系统复位中系统关闭了中断，初始化系统时钟等等。然后跳转到 __main进行堆栈初始化，最后跳转到.C文件中的main函数中执行相应的功能。【这里只做概述，过两天有时间了专门写一篇关于STM32启动流程分析的文章^-^】。

我们可以看到，系统初始化部分是必须的，关键我们要修改的就是最后这一步跳转，如和让程序跳转跳转到我们编写的APP代码中而不是跳到伪BOOT中的APP程序呢？其实这也是可以的，我们只需要将我们编写的用户APP程序中启动代码删掉，其余代码将伪BOOT中的用户程序代码覆盖掉就可以，但这样好像失去了IAP的意义。IAP本来就是期望用户“不拆机在线升级”。这样搞岂不是更复杂了？

所以，更常见的做法是：伪BOOT完成系统初始化后，进入APP程序，此时利用APP实现两个功能：

1. 检测是否需要升级某个用户APP

2. 跳转到指定APP运行空间运行

我们可以依靠UART,USB,IIC等一切板上通信外设完成第一个功能。如果需要升级或更新某个APP，则通过某种通信方式将我们编译好的bin文件发送到单片机上，单片机伪BOOT中的程序接收这些数据并根据需要使用FLASH写操作将这些代码写到指定的FLASH空间（这里我们只讨论FLASH）。当需要执行某个用户APP程序时，可以在伪BOOT的主程序中修改程序指针PC，使系统跳转到指定用户APP程序所在的FLASH空间，然后运行，就可以完成跳转到相应的APP程序的功能。

道理很简单。我们编写伪BOOT程序使之有通信，FLASH读写，地址跳转功能就可，在启动启动后，因为程序还运行在伪BOOT里，我们依靠BOOT程序中的功能，检测是否需要更新用户APP，需要更新则进行数据通信，并将数据通过FLASH操作写入FLASH，然后执行程序跳转指令，使系统跳转到对应的APP程序空间，就可以执行对应的程序功能。

这里有几个问题需要注意一下：

1. 我们并没有裁减掉用户APPx中的boot代码，所以某种程度来说，烧进FLASH中的至少是两套或两套以上的【boot+app】程序，只不过我们的伪BOOT是为了完成引导，其余的APP都是用户功能程序罢了。

2. 从问题1来看，既然每一个程序都是完整的，如果我们的伪BOOT通过串口接收到我们编译好的完成工程的bin文件，并写入到FLASH中0x08004000之后，那么0x08004000这个地址里面存放的是什么东西？用户APPx main函数地址？错！应该是用户APPx程序的BOOT代码的第一行，也就是程序代码的用户堆栈栈顶地址，那0x08004004理所当然就是APPx程序的BOOT代码里的系统中断复位指针。

3. 从问题1和2我们可以推断出，由伪BOOT引导后跳转到用户APP程序，系统又进行了一次复位操作，而且和伪BOOT是一模一样的复位操作，但此时有个明显的问题就是，我们的中断向量表多套，每套中断向量表都对应的是自己APP的中断入口，但是用户程序执行时遇到中断，跳转会跳到哪里去呢？如果我们在用户APP中不加以修改，中断向量表的偏移量仍旧是以0x08000000为基地址计算得到的，所以任何一个用户APP都会跳转到伪BOOT中的中断向量，造成不可预料错误。但是幸好STM32提供了中断向量偏移寄存器，我们可以通过修改这个寄存器的值，将每个APP程序的中断向量对应到自己所在空间的正确地址。完成中断操作。

4. FLASH空间是在编译链接后就确定的，所以在你下载程序之前，你的程序地址已经确定，这样我们就需要在keil的配置文件中更改ROM的地址，使APP程序可以烧写到一个正确的FLASH空间，即不会破坏其他程序空间，又能被正确引导启动，一般来讲，伪BOOT文件大小越小越好，这样可以为APP程序节留下很多空间。而我个人建议将伪BOOT文件单独放在第一扇区，即0x08000000-0x08003FFF【16KB】，因为程序中在进行FLASH写操作之前可能需要擦除，但往往擦除会擦除掉一整个扇区，如果对内存理解不到位或者程序编写有误，也会将伪BOOT擦除掉，使引导系统崩溃。

5. 我们的传输的APP程序一定经过keil编译过的完整的工程形成的二进制——bin文件。因为我们是将文件数据直接发送到开发板上，不经过特殊的解析，直接写入到FLASH中，所以这就要求我们发送的文件一定是内存中最终存储的二进制文件，而不是hex和axf文件。hex是十六进制文件，我们打开可以看到一串ASCII码，对应着地址信息和数据，而axf则包