嵌入式 > 技术百科 > 详情

stm8s 实践课程之IAP设计编码（bootloader实现）

发布时间：

项目实践1：Bootloader

1.项目介绍

在之前的例程和实践中，我们都是使用st-link调试下载的方式进行程序烧录。大家可能已经认识到这种烧录方式的弊端了。因为这种烧录方式首先必须要有以下几个工具或者软件：

1.烧录工具（不同芯片支持的工具不一样，有ST-Link，JTAG等）

2.已经安装了IDE（IAR或者SVD或者CCS等）或者与烧录工具匹配的烧录软件的电脑

3.烧录前后需要物理上电掉电（不建议ST-Link进行热插拔），即开/关电源.

也许大家会觉得，对于学习而言，这些都能忍受。但是如果真正做成产品，如果还是用这种方式进行升级，那代价就太大。举个例子吧，我之前的工作是开发和维护大功率的UPS（不间断电源），主要客户是一些大型企业，例如银行的数据中心，中国移动网络中心。UPS内部有许多ARM芯片，DSP芯片。这类应用场合，即便给程序升级，客户也不会让你断电的，而且因为安全性要求，一般MCU，DSP都是在产品内部，根本无法对外开放烧录盒的烧录接口。所以绝大部分嵌入式产品，都会开发Bootloader程序。

那么什么是Boot Loader呢？一般来说，嵌入式产品的软件都会分为两部分，第一部分为Bootloader，第二部分为主程序（Main APP），它们存放在flash的不同区域。Bootloader是上电或者复位以后先执行的，通过它，我们可以初始化硬件设备、建立内存空间的映射图，检测程序的完整性，判断是否需要从Bootloader跳转到APP或者更新APP。而主程序呢，则是真正用来实现产品面向客户的功能的。

通常呢，在Bootloader会实现一种或者一种以上的IAP方式，可能是UART，SPI，CAN或者Ethernet等。本次例程呢，就是设计一个Bootloader，允许用户用电脑的串口+超级终端实现烧录功能。

2.程序流程设计

秉承软件开发好习惯，coding前先想好思路，设计好流程框图，coding时才能事半功倍哦。

此次Bootloader程序主要分为三个模式：

1.升级模式Upgrade mode：对硬件初始化完成以后，率先检测这个模式，进入该模式的条件为，检测到升级程序的命令，否则进入下一个模式的检测。在这个模式下，指示灯闪烁速率最快，为50ms

2.正常模式Normal Mode：这个模式主要作用为检测主程序是否有效，如果有效则进行程序跳转进入主程序，否则进行下一个模式的检测。这边建议在主程序控制LED指示灯以其他的频率（例如500ms或者1s）闪烁，以示区别。

3.等待模式Wait Mode：如果上述两种模式都不满足，则停留在这个模式。这个模式主要作用为循环检测串口数据，如果有收到数据则进行解析，满足升级模式的进入条件则转到升级模式。该模式下，LED指示灯闪烁速率为200ms。

程序流程框图如下：

2.1.正常模式

从之前的程序流程图可以看出，我们已经将stm8s的flash分为了Bootloader和Main APP，所以如果没有接到烧录指令且Main APP的flash区域已经有了正常的程序，那么bootloader就跳转到Main APP执行。那么怎么判断Main APP已经有了程序了呢？这边我提供一个比较简单方法。我们可以在Main APP的代码中，把某串特定的字符通过伪指令放入特定的地址，那么Bootloader只要读取该地址与预先规定好的字符是否一致。一致的话则认为Main APP存在。本次实践，我在Main APP中将“XLXWW”字符放入flash的0x9FF8地址中。

当然如果对安全性要求更高的话，我们还可以定义更复杂的方式。业内比较通用的方式是除了刚才提到的方法，还会加上将整个Main APP的flash的值进行checksum校验等。

2.2.升级模式

升级指令会在在两种情况下收到：

1.芯片内部只有bootloader

2.芯片有bootloader和Main APP，且当前程序跑在Main APP。这种情况下，我们在跳转会Bootloader前需要先将这个信息写入EEPROM，bootloader才知道需要升级程序

下面定义了升级模式过程中的步骤：

1.如果之前未初始化UART，则首先初始化UART的配置；

2.上位机（PC）通过串口发送询问请求，包括系统型号，程序版本等信息，Bootloader根据自己的信息回复，如果上位机认为匹配成功，则进行下一步

3.上位机根据烧录文件的信息，发送开始烧录请求，请求包中包含了需要擦除的地址段。Bootloader根据上位机的请求，擦除对应地址的flash，成功后回复ok

4.上位机分段将flash的Data传送给你Bootloader，Bootloader将数据依次写入Flash空间

5.所有数据烧写完成后，上位机开始请求验证flash数据是否被正确写入。此时Bootloader分段读取flash数据，发送给上位机，上位机收到数据后与原始烧录文件的数据做对比，如果完全一致，则整个烧录过程结束，如果有不一致，则提示用户是否重新烧录。

2.3.等待模式

等待模式，其实就是由于Main APP不存在或者不完整，程序一直待在booloader. 在while循环里面，一直查询是否有收到串口数据。如果有则进行解析，并根据解析后的指令是进入升级模式还是丢弃这些不满足期望的数据。

3.前期准备和理论基础

3.1.Bootloader& Main APP

参看章节1的示意图，Bootloader和APP是独立的两个工程，它们拥有相互独立的flash地址空间，用于存放程度。

3.2.编译器是怎么生成烧录文件的

简单讲，编译器就是将“一种语言（通常为高级语言）”翻译为“另一种语言（通常为低级语言）”的程序。一个现代编译器的主要工作流程：源代码 (source code) →预处理器 (preprocessor) →编译器 (compiler) →目标代码 (object code) →链接器 (Linker) →可执行程序 (executables).

以IAR为例，编译可以细分为三个阶段：

源文件解析

IAR中有C/C++和汇编编译器，会根据实际项目中的源文件类型，翻译为中间目标文件. 这些文件具备特殊格式，可重定位，作为第二步链接器的输入文件。

2.链接

第一步生成的目标文件，只是一个中间产物，需要通过链接器进行链接，生成烧录文件。既然要链接，我们首先必须得有链接配置文件。Stm8s链接配置文件是.icf文件，默认情况下只要我们在工程设置中选取了device，编译器会自动找寻到对应的.icf作为配置文件。所以之前的课程中，并没有提及。但是在此次课程中，由于我们需要将flash分为两个部分，因此需要我们对自带的.icf进行适当的修改。详见3.2.

与此同时，链接器也可以生成其他文件，比较有参考意义的有.map文件。在.map文件里面我们可以详细的查看flash空间用了多少，一些全局变量和函数被分配到了flash的什么区域。

3.链接以后

链接器生成的一些文件，可以根据需要进一步转换为其他文件，例如给IAR的调试器,方便我们进行调试. 或者调用其他外部转换器，转为其他我们所想要格式的烧录文件。

3.2.如何将Bootloader和Main APP放入特定flash段

LINK链接器是按照用户在ICF文件中的规定来放置sections的，所以理解ICF文件的内容尤其重要。一个标准的ICF文件可包括下面这些内容：

-可编址的存储空间（memory）

-不同的存储器地址区域（region）

-不同的地址块（block）

-Section的初始化与否

-Section在存储空间中的放置

默认情况下IAR根据Device类别自动选取对应的icf文件，也可以根据需要选定自己写的icf文件，设置方法如下：Option-- Linker，选取自定义文件

所以我们需要分别为bootloader和main APP准备icf文件，里面定义的flash地址需要错开，RAM空间可以共用。下面是两个文件的部分对比，详细的内容请参见bootloader和main APP工程下的Linker文件夹。

3.3.Main APP和Bootloader间的切换和识别

3.3.1.Main APPàBootloader

Main APP切换到Bootloader的情形为，Main APP接收到烧录命令，需要跳转到Bootloader，然后由bootloader擦除Main APP的flash空间。所以这里存在两个问题：

1.Main APP如何跳转到Bootloader

2.Bootloader怎么分辨是从MainAPP跳入的，而不是系统硬复位

对于第一个问题，简单的来说，就是收到烧录指令后，我们人为地让程序进入Bootloader的flash首地址存储的地址中去。Bootloader中的flash开头存放的是中断向量表，PC跳到首地址以后，CPU会先取2个地址，第一个是栈顶地址，第二个是复位异常地址，然后执行复位初始化函数以后，转入执行bootloader的main函数。如此便开始执行bootloader。

第二问题，我们在ifc文件中定义一段RAM空间，属性为不需要初始化。正常来说，只要发生复位，不管是硬复位还是软复位，那么RAM区域都会初始化为0（跳入Main函数前的汇编代码中）。但是如果我们在icf文件中设定为不需要初始化，那么则会跳过这段区域的初始化。所以在跳转之前，我们将这片RAM区更新为某个特定的值，那么Bootloader开始阶段，以此判断即可。