这里以 KEIL 开发环境和 STM32F103RET6 为例。
上电时单片机首先进入复位中断 Reset_Handler,即汇编文件的复位中断处理函数。
并且有一个中断向量表默认存在于 flash 地址开始处。
为什么说是默认呢?这是因为如果没有特殊要求的话很少会去改中断向量表。实际上这个中断向量表是可以更改的。但是在更改向量表之前必须在地址开始处建立一个向量表,因为在复位后,程序默认(硬件决定的)从flash开始的第一个字读取栈指针,第二字就是复位中断的入口,并根据该指针最终进入复位处理函数中执行相应的函数。如果没有这个中断向量表程序是无法启动的。
那么既然前面说可以重新设定中断向量表的位置,那必然有一个寄存器记录着这张表的位置,这就是 VTOR 寄存器。从《Cortex-M3权威指南》可以看该寄存器的介绍:
并且向量表的偏移量有如下要求:
64*4 是因为一个表项为4字节。
更具体的关于更改向量表的信息查看《Cortex-M3权威指南》。
在复位处理函数中有进入 SystemInit 函数执行,在函数里有一个设置中断向量表的位置的语句。
VECT_TAB_OFFSET 默认情况下就是 0。
因为这是官方库函数,并且上电之后必定进入复位中断函数处理,因此必定会执行重新定位向量表的操作。因此只要修改宏定义就可以重新定位向量表。
先准备两个程序,一个为 bootloader,用于更新程序,一个为 APP,即固件程序。
首先确定 BootLoader 为上电最先执行的函数,需要通过下载器下载,而 APP 则可以通过有线(spi、i2c、usart、usb)、无线(Bluetooth、WiFi)等各种方式下载,只要能够正确传输数据即可。
因为两个程序中只能有一个程序正在运行,所以可以共用 RAM。所以这个时候对一些变量就有必要进行初始化,以防APP程序使用的 RAM 空间存在之前的数据。
上电之后,因为硬件问题(可能是 VTOR 寄存器断电不保存数据吧),导致单片机自动从中断向量表1中寻找复位中断处理函数,此时必然最终会进入 BootLoader 程序中执行。因为向量表第一个字( 32 字节)存放的地址就是 BootLoader 程序编译出来的中断处理函数地址。所以在这个程序一般就是初始化传输方式,然后在一定时间里判断是否需要更新固件,需要则将更新固件并跳转到第二个复位中断函数中执行,而如果超时则自动跳转到第二个复位中断函数中执行。
一般更新固件的文件类型为 bin 文件,文件可以直接拷贝到 flash 中并且执行。那么 bin 文件应该是怎样的呢?下面的就是通过 KEIL 生成的 bin 文件所含有的信息。(有关如何生成 bin 文件查看KEIL 生成 Bin\axf 文件)
和普通程序的生成没多大区别,都是编译器编译得到的目标的程序。但是我们要如何让编译将程序放在该放的地址呢,即在得到这个 bin 文件之后,当从向量表的第二字获取的地址刚好指向了 Reset_Handler 函数呢?即这里面存放的地址应该是绝对地址。
通过设置 KEIL 即可:
上面设置为 0x8001000,这样在编译过程中就会将整个程序的开始放在 0x8001000,并且其他函数地址也会根据该地址自动确定地址,而变量和栈等数据则存放在 0x20000000 开始处(和 BootLoader 一样,所以它们其实是共用 RAM),这样程序才能正确执行。但是 BootLoader 怎么找到 APP 的第一个函数的地址并进入执行呢?就是从接收到的 bin 文件里找。之前说过程序的开始处就是一张向量表(编译器自动处理的),也就是这个程序的向量表开始就在 0x8001000,而 bin 文件可以直接看成一个 flash 空间,程序应该放在 0x8001000,在 bin 文件就是在文件的开始处,这样就能找到栈顶指针和复位中断处理函数了。有点绕,看示意图(数字无意义):
但是 BootLoader 虽然找到了 APP 程序的复位向量地址,并且整个 APP 程序拷贝到 0x08001000 开始处了,BootLoader 程序可以通过跳转语句调到复位中断处理函数执行,并且能从向量表出得到栈顶位置,并且其他函数地址也由编译器确定了,执行应该是没问题的。但是一旦中断来了,根据 stm32 的中断机制,肯定会从中断向量表中找地址,而找中断向量表是通过 VTOR 来定位的,而在跳转后虽然进入了复位中断处理函数,并进入了 SystemInit() 中执行,也执行了重新设置 VTOR 寄存器的操作,但是你的 VECT_TAB_OFFSET 还是 0……这样一旦中断发生,通过 VTOR 定位又跑到 BootLoader 的向量表去执行处理程序了。所以在进入 APP 函数后,需要重新定位我们新的向量表,只需要修改 VECT_TAB_OFFSET 即可,而这个偏移量有限制……,而且这个偏移量其实也就是给 BootLoader 程序预留的空间,所以在这里 VECT_TAB_OFFSET 设置为 0x1000,符合限制条件,并且这个偏移量应该大于 BootLoader 程序的总大小,这样就 OK 了。
跳转到复位中断处理函数之前,必须重新设置栈顶位置,虽然是共用 RAM,但毕竟 BootLoader 程序编译下的 RAM 分配和 APP 程序编译下的 RAM 分配可能是不同的,需要重新确定栈顶位置。
总结:
1、BootLoader 两个功能,一个是一定时间内判断是否需要更新 APP,如果需要则接收并将其烧写到指定地址的 flash 空间中,并从该地址中获取栈顶指针和 Reset_Handler 指针,并跳转到该函数执行;另一个就是超时直接在该地址直接获取之前的栈顶指针和 Reset_Handler 指针并跳转执行。
2、APP程序需要让编译器将程序存放在指定地址空间里,并重新定位中断向量表的位置。
3、每次上电复位之后程序都会直接从 BootLoader 的 Reset_Handler 函数执行,而不是从APP中执行。
4、这个地址有两个限制:BootLoader 程序大小和向量表地址限制,必须两者都符合要求。
-------------------------------------------------------------------------2018/7/25 Osprey
了解了基础知识之后就可以使用某种传输方式进行bin文件的传输,这里介绍 YModem 协议,当然也可以使用 Modbus 等其他协议进行传输。YModem 协议是从 XModem 协议演变而来的,每包数据最多可以达到 1024 字节,是一个非常高效的文件传输协议。
下面是传输过程:
首先接收方发送字符 ‘C’,等待发送方接收,如果接收方没有准备好,则接收方持续发送 ‘C’。
接收方收到 C 后,开始发送第一帧数据:
字符:字符为 ASCII 码,指定的几个特定字符。比如 SOH,查询 ASCII 码可以知道是 0x01,它代表该帧有 128byte 数据。如果是 STX 则有 1024byte。
编号:编号从 0 开始,根据帧数增加,达到 0xFF从0 开始继续递增。比如第一帧发送文件名时的编号为 0x00。程序处理的时候在一开始设置一个变量为 0,每接收一帧数据递增,并且和接收的编号进行对比,如果接收的编号和程序的变量不一致,说明接收错误。编号的反码是对编号进行校验使用的,以确定编号的正确性。比如编号为 0x00,反码为 0xFF。
数据区:固定长度,不足的填充 0x00。可以是 128 字节也可以是 1024 字节,根据帧头字符确定。传输文件名时是完整的文件名,如 “helloword.bin”,后面填充 0。有的传输软件在传输完文件名这一帧数据后可能会再传输一帧含有文件大小的数据帧(数据区不足还是填充 0),可以根据实际情况测试。
CRC16:只对数据区进行校验,不对前三个字节校验。高字节在前,低字节在后。
接收方接收到第一帧含有文件名的数据帧之后,开始发送 ACK 进行确认应答,并发送字符 ‘C’,发送方收到 ‘C’ 后开始接收第二帧数据,这里包含文件内容的一部分。接收方接收到这帧数据后,发送 ACK 应答,等待第三帧数据,继续 ACK 应答,继续接收……知道接收方接收到所有数据。
当发送方发送完最后一帧数据并接收到 ACK 后,发送 EOT,接收方接收到之后,接收方发送 NAK,发送方继续发送 EOT,这一次接收方发送 ACK。然后接收方再发送 ‘C’,如果发送方没有下一个文件需要传输,就会发送如下帧:
SOH 00 FF 00~00(共128个) CRCH CRCL
接收方接收到后,正式结束此次传输。
ACK、NAK、EOT 的 ASCII 码如下:
下面为传输具体过程,以文件大小不足三帧数据为例,黄色为接收方发送的数据。
以下为 CRC 校验代码:
-------------------------------------------------------------------------2018/7/26 Osprey
以下操作方法是为公司的一个项目写的操作流程。
打开 SecureCRT 软件,可以从左边找到 Session Manager 窗口,如果没有,可以从 View -> Session Manager 打开。
然后输入英文字符 ‘1’,等待目标板发送 ‘c’。如下
注意:用户发送的数据不会在界面上显示出来(如果需要回显,需要进行设置 Session Options—>Advanced—>Localecho)。如果不能接收到目标板的信息,请重复上述操作。
此时可以看到正在传输 bin 文件,传输到 100% 时,传输完成,并且进入更新好的程序中执行。
----------------------------------------------------------------------------------------2018/8/23 Ospery
推荐阅读:
巧用补码
快来拼接你的代码!
STM32调试利器之ITM
C语言之#error/#warning
运算符 % 的妙用