STM32

STM32串口IAP实验（战舰STM32开发板实验）

2019-07-20 23:32发布

站内问答 / STM32/STM8
4558 48 1023
 

第四十八章 串口IAP实验

IAP，即在应用编程。很多单片机都支持这个功能，STM32也不例外。在之前的FLASH模拟EEPROM实验里面，我们学习了STM32的FLASH自编程，本章我们将结合FLASH自编程的知识，通过STM32的串口实现一个简单的IAP功能。fficeffice" />

48.1 IAP简介   

IAP（In Application Programming）即在应用编程，IAP是用户自己的程序在运行过程中对User Flash的部分区域进行烧写，目的是为了在产品发布后可以方便地通过预留的通信口对产品中的固件程序进行更新升级。 通常实现IAP功能时，即用户程序运行中作自身的更新操作，需要在设计固件程序时编写两个项目代码，
第一个项目程序不执行正常的功能操作，而只是通过某种通信方式(如USB、USART)接收程序或数据，执行对第二部分代码的更新；第二个项目代码才是真正的功能代码。这两部分项目代码都同时烧录在User Flash中，当芯片上电后，首先是第一个项目代码开始运行，它作如下操作： 　　 1）检查是否需要对第二部分代码进行更新 　　 2）如果不需要更新则转到4） 　　 3）执行更新操作 　　 4）跳转到第二部分代码执行 　　 第一部分代码必须通过其它手段，如JTAG或ISP烧入；第二部分代码可以使用第一部分代码IAP功能烧入，也可以和第一部分代码一起烧入，以后需要程序更新是再通过第一部分IAP代码更新。 　 我们将第一个项目代码称之为Bootloader程序，第二个项目代码称之为APP程序，他们存放在STM32 FLASH的不同地址范围，一般从最低地址区开始存放Bootloader，
紧跟其后的就是APP程序（注意，如果FLASH容量足够，是可以设计很多APP程序的，本章我们只讨论一个APP程序的情况）。这样我们就是要实现2个程序：Bootloader和APP。　 STM32的APP程序不仅可以放到FLASH里面运行，也可以放到SRAM里面运行，本章，我们将制作两个APP，一个用于FLASH运行，一个用于SRAM运行。 我们先来看看STM32正常的程序运行流程，如图48.1.1所示：


图48.1.1 STM32正常运行流程图        STM32的内部闪存（FLASH）地址起始于0x08000000，一般情况下，程序文件就从此地址开始写入。此外STM32是基于Cortex-M3内核的微控制器，其内部通过一张“中断向量表”
来响应中断，程序启动后，将首先从“中断向量表”取出复位中断向量执行复位中断程序完成启动，而这张“中断向量表”的起始地址是0x08000004，当中断来临，STM32的内部硬
件机制亦会自动将PC指针定位到“中断向量表”处，并根据中断源取出对应的中断向量执行中断服务程序。        在图48.1.1中，STM32在复位后，先从0X08000004地址取出复位中断向量的地址，并跳转到复位中断服务程序，如图标号①所示；在复位中断服务程序执行完之后，会跳转到我们
的main函数，如图标号②所示；而我们的main函数一般都是一个死循环，在main函数执行过程中，如果收到中断请求（发生重中断），此时STM32强制将PC指针指回中断向量表处，如图标号③所示；然后，根据中断源进入相应的中断服务程序，如图标号④所示；在执行完中断服务程序以后，程序再次返回main函数执行，如图标号⑤所示。        当加入IAP程序之后，程序运行流程如图48.1.2所示：
       在图48.1.2所示流程中，STM32复位后，还是从0X08000004地址取出复位中断向量的地址，并跳转到复位中断服务程序，在运行完复位中断服务程序之后跳转到IAP的main函数，
如图标号①所示，此部分同图48.1.1一样；在执行完IAP以后（即将新的APP代码写入STM32的FLASH，灰底部分。新程序的复位中断向量起始地址为0X08000004+N+M），跳转至
新写入程序的复位向量表，取出新程序的复位中断向量的地址，并跳转执行新程序的复位中断服务程序，随后跳转至新程序的main函数，如图标号②和③所示，同样main函数为一个
死循环，并且注意到此时STM32的FLASH，在不同位置上，共有两个中断向量表。        在main函数执行过程中，如果CPU得到一个中断请求，PC指针仍强制跳转到地址0X08000004中断向量表处，而不是新程序的中断向量表，如图标号④所示；程序再根据我们设置
的中断向量表偏移量，跳转到对应中断源新的中断服务程序中，如图标号⑤所示；在执行完中断服务程序后，程序返回main函数继续运行，如图标号⑥所示。        通过以上两个过程的分析，我们知道IAP程序必须满足两个要求： 1）  新程序必须在IAP程序之后的某个偏移量为x的地址开始； 2）  必须将新程序的中断向量表相应的移动，移动的偏移量为x； 本章，我们有2个APP程序，一个为FLASH的APP，程序在FLASH中运行，另外一个位SRAM的APP，程序运行在SRAM中，图48.1.2虽然是针对FLASH APP来说的，但是在

SRAM里面运行的过程和FLASH基本一致，只是需要设置向量表的地址为SRAM的地址。 1.APP程序起始地址设置方法 随便打开一个之前的实例工程，点击Options for TargetàTarget选项卡，如图48.1.3所示：
图48.1.3 FLASH APP Target选项卡设置        默认的条件下，图中IROM1的起始地址（Start）一般为0X08000000，大小（Size）为0X80000，即从0X08000000开始的512K空间为我们的程序存储（因为我们的STM32F103ZET6的
FLASH大小是512K）。而图中，我们设置起始地址（Start）为0X08010000，即偏移量为0X10000（64K字节），因而，留给APP用的FLASH空间（Size）只有0X80000-0X10000=0X70000
（448K字节）大小了。设置好Start和Szie，就完成APP程序的起始地址设置。        这里的64K字节，需要大家根据Bootloader程序大小进行选择，比如我们本章的Bootloader程序为22K左右，理论上我们只需要确保APP起始地址在Bootloader之后，
并且偏移量为0X200的倍数即可（相关知识，请参考：http://www.openedv.com/posts/list/392.htm）。这里我们选择64K（0X10000）字节，留了一些余量，方便Bootloader以后的升级修改。        这是针对FLASH APP的起始地址设置，如果是SRAM APP，那么起始地址设置如图48.1.4所示：

图48.1.4 SRAM APP Target选项卡设置        这里我们将IROM1的起始地址（Start）定义为：0X20001000，大小为0XA000（40K字节），即从地址0X20000000偏移0X1000开始，存放APP代码。因为整个STM32F103ZET6的
SRAM大小为64K字节，所以IRAM1（SRAM）的起始地址变为0X2000B000（0x20001000+0xA000=0X2000B000），大小只有0X5000（20K字节）。这样，整个STM32F103ZET6的SRAM
分配情况为：最开始的4K给Bootloader程序使用，随后的40K存放APP程序，最后20K，用作APP程序的内存。这个分配关系大家可以根据自己的实际情况修改，不一定和我们这里的设
置一模一样，不过也需要注意，保证偏移量为0X200的倍数（我们这里为0X1000）。        2.中断向量表的偏移量设置方法        之前我们讲解过，在系统启动的时候，会首先调用systemInit函数初始化时钟系统，同时systemInit还完成了中断向量表的设置，我们可以打开systemInit函数，看看函数体的结尾处有这样几行代码： #ifdef VECT_TAB_SRAM SCB->VTOR = SRAM_BASE | VECT_TAB_OFFSET;  /* Vector Table Relocation in Internal SRAM. */ #else SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal FLASH. */ #endif 从代码可以理解，VTOR寄存器存放的是中断向量表的起始地址。默认的情况VECT_TAB_SRAM是没有定义,所以执行SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET;   对于FLASH APP，我们设置为FLASH_BASE+偏移量0x10000,所以我们可以在FLASH APP的main函数最开头处添加如下代码实现中断向量表的起始地址的重设： SCB->VTOR = FLASH_BASE | 0x10000;        以上是FLASH APP的情况，当使用SRAM APP的时候，我们设置起始地址为：SRAM_bASE+0x1000,同样的方法，我们在SRAM APP的main函数最开始处，添加下面代码： SCB->VTOR = SRAM_BASE | 0x1000;        这样，我们就完成了中断向量表偏移量的设置。 通过以上两个步骤的设置，我们就可以生成APP程序了，只要APP程序的FLASH和SRAM大小不超过我们的设置即可。不过MDK默认生成的文件是.hex文件，并不方便我
们用作IAP更新，我们希望生成的文件是.bin文件，这样可以方便进行IAP升级（至于为什么，请大家自行百度
友情提示: 此问题已得到解决，问题已经关闭,关闭后问题禁止继续编辑，回答。
该问题目前已经被作者或者管理员关闭, 无法添加新回复
48条回答
正点原子
1楼-- · 2019-07-21 19:33
回复【8楼】正点原子:
---------------------------------
额  复位是一定要设计复位电路的吗 或者软件复位吗
为什么我掉电再上电还是跑的是APP程序- -！
charlieholy
2楼-- · 2019-07-21 23:53
回复【9楼】charlieholy:
---------------------------------
不会吧。
正点原子
3楼-- · 2019-07-22 01:02
 精彩回答 2  元偷偷看……
charlieholy
4楼-- · 2019-07-22 02:33
回复【楼主位】Admin:
---------------------------------
楼主，你好。
看了你的很多文章，钦佩你的技术，感谢你对大家的帮助。（好听的话少说，进入正题！）
--------------
您提到 用 fromelf.exe 生成bin文件，然后再 下载到 应用程序区域。
我在生成app.bin时，碰到了困难：
只要我在MDK中，给app程序设置一个flash偏移地址（即不是从0x8000000开始），就无法生成app.bin文件，得到的是一个杂乱的app文件夹。！！！！！！
----------------
我检查了，fromelf的配置没有问题，该配置能在boot程序（从0x8000000开始）中 生成对应的bin，路径也没问题。
该配置也能正确转化其它*.axf文件。
但就是不能转化 flash 有偏移地址的*.axf文件。
另外：
1、我的bootloader 已完成，可以正常进入用户程序；
2、我的app程序， 也能从用户程序 软复位 进入bootloader；后来用某烧写器软件，非常繁琐地把app.hex转成 app.bin，再下载到app区域，功能ok。
+++++++++++++++++++++++++++++++++++++++++++++
盼请原子大师指点：
为何在设置flash偏移地址后，我的fromelf 就无法生成bin文件了呢。
xaitstu
5楼-- · 2019-07-22 05:47
附上你的工程，我测试下。
正点原子
6楼-- · 2019-07-22 09:10
 精彩回答 2  元偷偷看……
上一页 1 2 3 4 5 6 7 8 下一页

一周热门 更多>