CN105117253A - 一种基于BootLoader的UV LED固化系统远程升级方法 - Google Patents

Abstract

本发明公开了一种基于BootLoader的UV？LED固化系统远程升级方法，系统管理分配用户程序区、升级储存区、参数保存区的FLASH存储地址的分配；通过接受上位机的请求判断是否进行升级；通过接受上位机的请求进行程序版本号、验证码等信息传输；升级结束后完成向用户程序的跳转。本发明将Bootloader与IAP结合，通过上位机通讯或配置GPRS、WiFi、以太网卡等通信模块完成的远程升级系统，集成在一个UV？LED控制设备上，可完成设备的远程调试、程序更新，大大减少了维护成本和维护周期。

Description

一种基于BootLoader的UV LED固化系统远程升级方法

技术领域

本发明涉及UVLED固化设备和工业控制等技术领域，尤其涉及一种基于BootLoader的UVLED固化系统远程升级方法。

背景技术

随着科学技术的发展，各类印刷行业中的固化工艺正发生颠覆性的变化。传统的长时间、大风速、高热量的热风固化工艺由于其效率低、高耗能、不环保等致命性弱点已渐渐被行业所淘汰，紫外光固化技术一经研制成功就得到了迅速普及与发展。在倡导节能环保的当今，业界一直致力于改进，而紫外线二极管(UltravioletLightEmittingDiode，UVLED)技术的出现随即引起一场轰动，UVLED固化技术开始广泛的应用到各个行业中，例如印刷、PCB曝光等。

目前UVLED固化系统大都处在研发阶段，现有的技术仅能制造出单一功能的设备。而市场对固化设备的功能、控制要求是多样的，如点胶行业要求UVLED固化控制方式为脚踏控制，时间可由人工控制；大型写真喷绘UVLED固化控制方式为喷绘机内部PLC编程控制；医疗行业的UVLED杀菌控制由光源控制器直接控制等等。面对这些不同的要求，大部分厂商依靠设计各种不同的机型和建立庞大的售后服务网络来满足各个行业对UVLED的控制需求。这样不但大大增加了产品的设计周期，同时使产品的附加成本大幅提高。针对这样的现状，提出了一种基于BootLoader的UVLED固化系统远程升级方法。

在嵌入式操作系统中，BootLoader是运行在操作系统内核之前的程序。可以初始化硬件设备、建立内存空间映射图，从而将系统的软硬件环境带到一个合适状态，以便为最终调用操作系统内核准备好正确的环境。在通常的嵌入式系统中，整个系统的加载启动任务就完全由BootLoader来完成。一般的嵌入式系统中，系统在上电或复位时通常都从地址0x00000000处开始执行，而在这个地址处安排的通常就是系统的BootLoader程序。

远程升级技术是建立在嵌入式系统的IAP技术上的。IAP，全称是“In-ApplicationProgramming”，中文解释为“在程序中编程”。IAP是一种通过微处理器的通信接口(如USART，IIC，CAN，USB，以太网接口甚至是无线射频通道)对正在运行程序的微处理器进行内部程序更新的技术(完全有别于ICP或者ISP技术)。

目前，基于BootLoader的系统远程升级的应用研究在固化系统领域里并不多，而厂商大多采用传统的技术人员现场调试、下载程序，有着效率和经济上的严重缺点。

发明内容

为了克服现有技术存在的缺陷，本发明提出了一种基于BootLoader的UVLED固化系统远程升级方法。本发明将Bootloader与IAP结合，通过上位机通讯或配置GPRS、WiFi、以太网卡等通信模块完成的远程升级系统，集成在一个UVLED控制设备上，可完成设备的远程调试、程序更新，大大减少了维护成本和维护周期。

本发明的技术方案为：一种基于BootLoader的UVLED固化系统远程升级方法，包括步骤：

步骤1，根据处理器模块、光源驱动模块中的STM32F103R8T6的内存架构完成对内存页的分配，将FLASH分为四个区，即BootLoader、用户程序区、升级存储区、参数保存区，并初始化BootLoader；

步骤2，BootLoader初始化结束后，判断参数保存区中的升级标志Updata_Flag，若升级标志为0xFA，说明接收到远程升级指令，接着判断是处理器模块的程序升级还是光源驱动模块的程序升级；确定后相应的模块则由BootLoader引导程序跳转进入升级程序，程序跳转指令符合STM32F10X系列的指令协议，升级确认指令反馈给上位机；

步骤3，STM32F103R8T6微处理器调用FLASH擦除函数Flash_SectorErase()按页擦除FLASH中升级储存区的相应数据，并注意将程序存储的地址与FLASH进行页对齐，每页占用2048bit；

步骤4，为了保证程序的安全，本发明引入抗误码环节，上位机在对新程序BIN文件分包的环节会按照一定格式打包成每一个数据包；

步骤5，数据引导包接收完毕后，BootLoader中的升级程序会根据引导包的信息进行数据包的接收，每包数据接收完毕后会在控制器端再次计算CRC，并校验是否与数据包中的CRC校验码相同，若不相同则会重新申请本序号的数据包，并以5次申请为限，若5次都错误则退出升级；若相同则申请下一包的发送，直到所有的数据包发送完毕；

步骤6，为了加强系统的抗误码能力，除了对每个数据包的校验，还会在最后对总数据包进行校验；

步骤7，确认升级成功后，客户端的BootLoader程序会将当前的版本号保存进FLASH的参数区中，并上传给上位机存储，至此升级过程确认成功。

进一步，所述UVLED固化系统主要包含通信模块、处理器模块、光源驱动模块以及交互模块，所述通信模块通过RS485分别连接处理器模块、光源驱动模块，所述处理器模块用于控制整个系统的运行，所述光源驱动模块用于控制电流的分配，所述交互模块和处理器模块相连，用于UVLED固化系统的显示和手动输入。

进一步，所述步骤1中，BootLoader是嵌入式系统在上电后执行的第一段代码，在完成初始化硬件设备、建立内存空间映射后，再跳转到操作系统映像或固化的嵌入式应用程序的内存空间，启动运行系统；用户程序区是储存需要运行的用户程序；升级存储区是用来暂时存储新的程序的二进制文件，待校验完成后再写入用户程序区；参数保存区内定义一个升级状态的结构体，成员包括升级标志，最近一次的升级信息，CRC校验码。

进一步，所述BootLoader以及用户程序区的首地址，需要在KEIL中的Optionsfortarget中手动设置为0x8000000和0x8010000。

进一步，所述步骤3在擦除的过程中，Flash_SectorErase()会返回每页的擦除结果，将擦除的结果返回给上位机；若擦除成功则开始请求数据引导包，若不成功则由上位机询问是否结束升级；数据引导包是上位机对新程序BIN文件解析并分包后生成的，引导包中包含程序包的总包数、总字节数、版本号及总CRC(16BitMODELBUS模式)校验码。

进一步，所述步骤4中具体过程为：每个数据包分别含有帧头(1Bit)、序号(1Bit)、文件长度(2Bit)、文件数据(1024Bit以内)、校验码(2Bit)、帧尾(1Bit)；帧头和帧尾是根据通信协议固定的0x5A和0xA5；校验环节采用的是CRC(16BitMODELBUS模式)，上位机在传输数据包前对每一数据包计算一次CRC并生成校验码；STM32F103R8T6微处理器在每一包数据的接收后都会校验CRC，如果校验不成功则发出错误指令，要求重新发送一遍当前数据包。

进一步，所述步骤6还包括：全部数据包传输完成后，上位机和STM32F103R8T6微处理器都会对这些储存的CRC校验码做一个总的CRC，判断上位机与微处理器计算得到的总CRC校验码是否一致，若不一致也会判断为升级失败。

本发明的有益效果为：

1)本发明将Bootloader与IAP结合，通过上位机通讯或配置GPRS、WiFi、以太网卡等通信模块完成的远程升级系统，集成在一个UVLED控制设备上，可完成设备的远程调试、程序更新。由于固化行业的特殊性，技术人员需要经常根据不同的流水线调试固化设备的程序。本发明提出的性能可靠的远程升级方案，不再需要技术人员奔赴各个工业现场进行程序的调试和升级，极大程度上减少了维护成本和调试周期，带来经济和时间的利益。

2)步骤1中创新地将STM32F103R8T6的FLASH分为四个区，较传统IAP升级多出了升级存储区和参数保存区。升级过程中不会直接覆盖用户程序区，而是将程序文件先放置于升级存储区，待验证没有问题之后，由Bootloader引导直接运行新程序，若发现新程序有编程上的缺陷，还可以恢复运行原有的程序，大大增强了升级过程的稳定性。此外，分配处参数保存区，在升级过程中将升级状态和校验参数保存在该区内，一旦升级过程中出现突发状况导致升级终止，重新升级时可读出上次升级的状态，在断点处继续传输数据包。断点续传的机制可以在使用GPRS作为传输模块的机型上大大减少了昂贵的流量的消耗。

3)步骤4、5、6中，两次CRC校验的设计不但保证了数据的安全性，在一般的IAP升级的校验环节上增加的对单个数据包的CRC验证环节，当单个数据包验证错误时不会退出升级，而是重新尝试发送该数据包。这样的设计是基于无线传输中不可避免的误码率，避免了一个数据包出现错误而导致整个升级过程终止，节约了升级时间和数据流量。

附图说明

图1是系统原理框图；

图2是STM32F103R8T6内部Flash规划图；

图3是数据帧格式说明图；

图4是方法流程图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能理解为对本发明的限制。

本发明所述的基于BootLoader的UVLED固化系统远程升级方法，包括以下模块：

(1)BootLoader模块。管理分配用户程序区、升级储存区、参数保存区的FLASH存储地址的分配；通过接受上位机的请求判断是否进行升级；通过接受上位机的请求进行程序版本号、验证码等信息传输；升级结束后完成向用户程序的跳转。

(2)上位机模块。运行在工控机上的电脑软件，控制升级文件的读取、解析、打包等。上位机软件与设备商的服务器连接，做到及时推送升级程序和调试程序等。上位机通过工控机的RS485总线与设备进行连接。

(3)可选的通信模块(GPRS、WiFi、蓝牙或以太网卡等)与上位机搭配，完成远程传输。

如图1所示，UVLED固化系统主要包含处理器模块、通信模块、光源驱动模块以及交互模块(包含触摸屏和按键模块，用于UVLED固化系统的显示和手动输入控制)。其中需要程序控制的有两个模块，即处理器模块(控制整个系统的运行)和光源驱动模块(控制电流的分配)，所述通信模块通过RS485分别同处理器模块、光源驱动模块相连，所述通信模块还通过网络与无线模块相连，无线模块通过RS485和上位机相连，配合上位机和网络即可对程序进行远程升级，大大缩短机器维护升级的时间。本发明以UVLED固化系统使用的STM32系列微处理器STM32F103R8T6为例。处理器模块、光源驱动模块的控制核心都是STM32F103R8T6微处理器，BootLoader在用户程序前运行，可完成初始化设备，建立内存空间映射，从而将软硬件调整到一个合适运行的环境，以便为最终调用操作系统内核做准备。利用这个特点，可以编写BootLoader程序，最终可以达到升级程序的目的。

本发明使用Cortex-M3架构的STM32F103R8T6作为UVLED固化系统的微处理器，利用基于BootLoader的IAP结合上位机或可选的通信模块完成UVLED固化系统远程升级。UVLED固化系统主要包含以下四个模块：处理器模块、通信模块、光源驱动模块以及交互模块。本发明提出的方法是基于处理器模块和通信模块完成的。就可行性而言，常见微处理器中都包含BootLoader。STM32F103R8T6微处理器支持IAP技术的首要前提为其必须是基于可重复编程闪存的微处理器。此外STM32微处理器拥有在数量上、种类上都非常丰富的外设通信接口，因此在STM32上实现基于BootLoader的IAP、完成远程升级是完全可行的。

处理器模块中，在STM32F103R8T6微处理器的FLASH区域中开辟出BootLoader的存放区域(地址可自定义)，其中存储有BootLoader的启动程序。启动BootLoader程序，程序会接受由上位机传送的升级指令，程序根据当前的状态进行一个综合判定，若需要升级，则BootLoader会调用存放在BootLoader中的升级程序，配合通信模块完成升级数据的传输，对FLASH中的运行程序区内的数据执行升级操作。

通信模块中，本发明使用STM32F103R8T6微处理器的RS485总线完成与上位机的通信，上位机完成升级引导包、升级数据包、升级状态包、校验包及程序版本号的等数据向微处理器的传输。

如图4所示，对基于BootLoader的UVLED固化系统远程升级方法进行阐述，主要包括以下步骤：

步骤1，根据STM32F103R8T6的内存架构完成对内存页的分配。本发明按照如图2所示的地址将FLASH分为四个区，即BootLoader，用户程序区，升级存储区，参数保存区。BootLoader是嵌入式系统在上电后执行的第一段代码，在完成初始化硬件设备、建立内存空间映射后，再跳转到操作系统映像或固化的嵌入式应用程序的内存空间，启动运行系统；用户程序区是储存需要运行的用户程序；升级存储区是用来暂时存储新的程序的二进制文件，待校验完成后再写入用户程序区；参数保存区内定义一个升级状态的结构体，成员包括升级标志，最近一次的升级信息，CRC校验码等等。其中BootLoader以及用户程序的首地址，需要在KEIL中的Optionsfortarget中手动设置为0x8000000和0x8010000；其他的均在BootLoader里设置。整个BootLoader共占8K字节。

步骤2，UVLED固化系统中需要程序控制的有两个模块，即处理器模块(控制整个系统的运行)和光源驱动模块(控制电流的分配)。模块的控制核心都是STM32F103R8T6微处理器。BootLoader初始化结束后，判断参数保存区中的升级标志Updata_Flag，若升级标志为0xFA，说明接收到远程升级指令，接着判断是处理器模块的程序升级还是光源驱动模块的程序升级。确定后相应的模块则由BootLoader引导程序跳转进入升级程序，程序跳转指令符合STM32F10X系列的指令协议。升级确认指令反馈给上位机。

步骤3，STM32F103R8T6微处理器调用FLASH擦除函数Flash_SectorErase()按页擦除FLASH中升级储存区的相应数据；由于该库函数对FLASH执行的是分页擦除，故需要注意将程序存储的地址与FLASH进行页对齐(每页占用2048bit)。擦除的过程中，Flash_SectorErase()会返回每页的擦除结果，将擦除的结果返回给上位机。若擦除成功则开始请求数据引导包，若不成功则由上位机询问是否结束升级。数据引导包是上位机对新程序BIN文件解析并分包后生成的，引导包中包含程序包的总包数、总字节数、版本号及总CRC(16BitMODELBUS模式)校验码。

步骤4，由于传输环节不可避免出现误码，尤其是使用GPRS、Zigbee作为远程载体时，有一定的误码率；所以为了保证程序的安全，本发明引入抗误码环节。上位机在对新程序BIN文件分包的环节会按照一定格式打包成每一个数据包。如图3所示，每个数据包分别含有帧头(1Bit)、序号(1Bit)、文件长度(2Bit)、文件数据(1024Bit以内)、校验码(2Bit)、帧尾(1Bit)等。帧头和帧尾是根据通信协议固定的0x5A和0xA5。校验环节采用的是CRC(16BitMODELBUS模式)，上位机在传输数据包前对每一数据包计算一次CRC并生成校验码。微处理器在每一包数据的接收后都会校验CRC，如果校验不成功则发出错误指令，要求重新发送一遍当前数据包。这种校验方式相对于总CRC校验而言，调整周期短、可靠性高。

步骤5，数据引导包接收完毕后，BootLoader中的升级程序会根据引导包的信息进行数据包的接收。每包数据接收完毕后会在控制器端再次计算CRC，并校验是否与数据包中的CRC校验码相同，若不相同则会重新申请本序号的数据包，并以5次申请为限，若5次都错误则退出升级；若相同则申请下一包的发送，直到所有的数据包发送完毕。每包校验无误后执行写FLASH操作，使用STM32库函数中的写FLASH函数FLASH_ProgramWord()；注意写入的最小单元是字(32bit)而非一般单片机是以半字(16bit)的方式写入的，不满的字节需用0xFF填充。以这样的方式，循环地将所有数据包中的程序代码写入FLASH的程序区。

步骤6，为了加强系统的抗误码能力，除了对每个数据包的校验，还会在最后对总数据包进行校验。上位机在解析包时就对程序的二进制文件的所有字节做CRC校验，耗费时间较长，会削弱用户体检；而改为在发送时校验，将每包帧中校验单元的两个字节单独进行保存(客户端也同样保存到FLASH中的参数区)。全部数据包传输完成后，上位机和微处理器都会对这些储存的CRC校验码做一个总的CRC，判断上位机与微处理器计算得到的总CRC校验码是否一致，若不一致也会判断为升级失败。进一步增强了系统的抗误码性。

步骤7，确认升级成功后，客户端的BootLoader程序会将当前的版本号保存进FLASH的参数区中，并上传给上位机存储，至此升级过程确认成功。最后BootLoader执行程序跳转指令Jump_To_Application()；在执行此跳转指令之前，需要初始化用户程序的堆栈指针，设定__set_MSP(*(__IOuint32_t*)APPLICATION_ADD)指令。至此，所有升级程序完成。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示意性实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管已经示出和描述了本发明的实施例，本领域的普通技术人员可以理解：在不脱离本发明的原理和宗旨的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由权利要求及其等同物限定。

Claims (7)

1.一种基于BootLoader的UVLED固化系统远程升级方法，其特征在于，包括步骤：

步骤1，根据处理器模块、光源驱动模块中的STM32F103R8T6的内存架构完成对内存页的分配，将FLASH分为四个区，即BootLoader、用户程序区、升级存储区、参数保存区，并初始化BootLoader；

步骤2，BootLoader初始化结束后，判断参数保存区中的升级标志Updata_Flag，若升级标志为0xFA，说明接收到远程升级指令，接着判断是处理器模块的程序升级还是光源驱动模块的程序升级；确定后相应的模块则由BootLoader引导程序跳转进入升级程序，程序跳转指令符合STM32F10X系列的指令协议，升级确认指令反馈给上位机；

步骤3，STM32F103R8T6微处理器调用FLASH擦除函数Flash_SectorErase()按页擦除FLASH中升级储存区的相应数据，并注意将程序存储的地址与FLASH进行页对齐，每页占用2048bit；

步骤4，为了保证程序的安全，本发明引入抗误码环节，上位机在对新程序BIN文件分包的环节会按照一定格式打包成每一个数据包；

步骤5，数据引导包接收完毕后，BootLoader中的升级程序会根据引导包的信息进行数据包的接收，每包数据接收完毕后会在控制器端再次计算CRC，并校验是否与数据包中的CRC校验码相同，若不相同则会重新申请本序号的数据包，并以5次申请为限，若5次都错误则退出升级；若相同则申请下一包的发送，直到所有的数据包发送完毕；

步骤6，为了加强系统的抗误码能力，除了对每个数据包的校验，还会在最后对总数据包进行校验；

步骤7，确认升级成功后，客户端的BootLoader程序会将当前的版本号保存进FLASH的参数区中，并上传给上位机存储，至此升级过程确认成功。

2.根据权利要求1所述的基于BootLoader的UVLED固化系统远程升级方法，其特征在于，所述UVLED固化系统主要包含通信模块、处理器模块、光源驱动模块以及交互模块，所述通信模块通过RS485分别连接处理器模块、光源驱动模块，所述处理器模块用于控制整个系统的运行，所述光源驱动模块用于控制电流的分配，所述交互模块和处理器模块相连，用于UVLED固化系统的显示和手动输入。

3.根据权利要求1所述的基于BootLoader的UVLED固化系统远程升级方法，其特征在于，所述步骤1中，BootLoader是嵌入式系统在上电后执行的第一段代码，在完成初始化硬件设备、建立内存空间映射后，再跳转到操作系统映像或固化的嵌入式应用程序的内存空间，启动运行系统；用户程序区是储存需要运行的用户程序；升级存储区是用来暂时存储新的程序的二进制文件，待校验完成后再写入用户程序区；参数保存区内定义一个升级状态的结构体，成员包括升级标志，最近一次的升级信息，CRC校验码。

4.根据权利要求3所述的基于BootLoader的UVLED固化系统远程升级方法，其特征在于，所述BootLoader以及用户程序区的首地址，需要在KEIL中的Optionsfortarget中手动设置为0x8000000和0x8010000。

5.根据权利要求1所述的基于BootLoader的UVLED固化系统远程升级方法，其特征在于，所述步骤3在擦除的过程中，Flash_SectorErase()会返回每页的擦除结果，将擦除的结果返回给上位机；若擦除成功则开始请求数据引导包，若不成功则由上位机询问是否结束升级；数据引导包是上位机对新程序BIN文件解析并分包后生成的，引导包中包含程序包的总包数、总字节数、版本号及总CRC(16BitMODELBUS模式)校验码。

6.根据权利要求1所述的基于BootLoader的UVLED固化系统远程升级方法，其特征在于，所述步骤4中具体过程为：每个数据包分别含有帧头(1Bit)、序号(1Bit)、文件长度(2Bit)、文件数据(1024Bit以内)、校验码(2Bit)、帧尾(1Bit)；帧头和帧尾是根据通信协议固定的0x5A和0xA5；校验环节采用的是CRC(16BitMODELBUS模式)，上位机在传输数据包前对每一数据包计算一次CRC并生成校验码；STM32F103R8T6微处理器在每一包数据的接收后都会校验CRC，如果校验不成功则发出错误指令，要求重新发送一遍当前数据包。

7.根据权利要求1所述的基于BootLoader的UVLED固化系统远程升级方法，其特征在于，所述步骤6还包括：

全部数据包传输完成后，上位机和STM32F103R8T6微处理器都会对这些储存的CRC校验码做一个总的CRC，判断上位机与微处理器计算得到的总CRC校验码是否一致，若不一致也会判断为升级失败。