Cortex-M3内核芯片LPC1778程序远程升级的实现

1 远程升级所需硬件资源

远程升级功能使用的硬件资源Cortex-M3内核LPC1778、外部Data FLASH、EEPROM、GPRS/4G通信模块，硬件连接示意图如图1所示。

图1 远程升级所需硬件资源方框图

（1）GPRS通信模块，数据透明传输，通过UART接口与LPC1778连接，实现远程通信。

（2）Cortex-M3内核LPC1778，具有96KB RAM、512KB的FLASH，提供IAP接口函数[1]，为程序的远程更新提供了必要条件。

（3）I2C接口的EEPROM，用于保存程序远程升级时所需的参数，例如：程序升级标志，数据包总数、数据包接收标志等，通过这些参数可实现定时升级以及断点续传等功能。

（4）SPI接口的Data FLASH，用于保存接收到的新版本的程序数据以及备份老版本的程序。Data FLASH共1M Bytes，其中512K Bytes（留有余量）用于保存新版本的程序，另外512K Bytes用于备份老版本的程序。Data FLASH容量的选择是跟所使用的MCU的FLASH大小相关的，即Data FLASH的容量要大于等于2倍的MCU 的FLASH大小。因为本设计中选用的MCU（LPC1778）的FLASH大小为512KB，所以相应的Data FLASH就选1M Bytes。

2 远程升级的程序实现方案

在本方案中，将终端程序分为引导程序（类似Bootloader，此Bootloader并非固化在LPC1778芯片内部用于支持ISP的代码，而是由用户编写的代码）和应用程序。

其中，引导程序被定位在LPC1778 FLASH的地址0x0—0x7FFF位置，这样一来，系统一旦复位最先运行的就是引导程序（ISP模式除外）。引导程序的存储空间大小分配为32KB，因此编写引导程序时，必须不能超过32KB，否则会覆盖到应用程序代码，造成启动异常。应用程序代码的地址则是从0x8000—0x7FFFF，共480KB，即应用程序的代码量不能超过480KB。这480KB的应用程序都可以通过GPRS模块进行远程的更新。

2.1 引导程序（Bootloader）

引导程序的主要作用是在系统复位时，进行一些初始化，然后从EEPROM中读取参数并判断是否要更新应用程序或是跳转到应用程序执行。如果要进行应用程序的更新，则从Data Flash中读取数据并调用IAP函数完成程序的更新，更新完成并校验通过后跳转到应用程序。引导程序流程如图2所示。

图2 引导程序流程图

需要注意的是，系统复位时，中断向量表是固定在地址0x00000000，引导程序正是存放于该位置开始的地方，因此是可以运行的。但应用程序的代码是从0x8000的地址开始存放的，因此引导程序在跳转到应用程序之前还需要将中断向量表重新映射到0x8000的位置，否则程序无法正常运行。当然，中断向量表的重新映射对于LPC1778并非难事，因为该芯片提供了一个向量表偏移寄存器，只需要向该寄存器写入应用程序的起始地址0x8000即可。另外，引导程序加载应用程序时需要重新设置堆栈指针及PC指针，这部分最好用汇编语言实现。代码如下：

__asm void app_boot_load( uint32 app_address )

{

LDR SP, [R0] ;加载应用程序堆栈指针地址

LDR PC, [R0, #4] ;加载应用程序PC指针地址

}

该函数的入口参数app_address即为应用程序的起始地址0x8000，因为只有一个参数，通过寄存器R0进行传递。执行完以上程序后，即实现了引导程序加载应用程序的过程。此时，引导程序释放内存并完全让出CPU的使用权，交由应用程序使用。

2.2 应用程序

应用程序即系统的主程序，为实现系统功能而编写。对于照明监控终端，主要实现通信、交流采集、开关量采集、控制输出等功能，而对于热网智能终端则是实现通信、模拟量信号采集（温度、压力、流量、脉冲信号）、流量累积、热量累积、数据记录等功能。另外应用程序还按照制订好的通信协议（见2.3），实现对远程升级数据的接收、应答、保存等。应用程序中远程升级数据交互的流程图如图3所示。

图3 应用程序中远程升级数据接收流程图

主站软件在下发程序数据包时，终端无论是否接收成功都是不应答的。这主要是考虑GPRS通信的特点，网络状况好的时候，可以连续的发数据，提高发送效率，如果采用应答的方式则效率会下降很多。主站在下发完所有数据包后，从终端读取数据包状态，即可了解哪些包没有发送成功，未发送成功的再次重发。因为终端保存了所有数据包的接收状态，这样也就很容易实现通信中断后的数据续传。

另外，为了实现升级时备份老版本的程序，将Data FLASH分了2个区（见第2节第4条），定义为H区和L区。终端初次运行时，将目前运行的版本的程序备份在Data FLASH的H区（仅在初次运行时备份）。第一次远程升级时，将接收到的新版本的程序数据保存在L区，这样在H区的就是老版本的程序，而L区的就是新版本的程序。再次远程升级时则是将数据保存在H区，L区的程序则变成了老版本的备份程序。这样循环交替，就始终保证L区，H区一个是新版本程序，一个为老版本程序。一旦升级出现问题，引导程序还能恢复老版本的程序，提高了可靠性。

根据本方案，应用程序中仅仅是完成远程升级数据的接收、保存，并不直接进行程序的更新，即没用调用IAP函数进行代码的替换更新。所以数据的交互过程对程序正在运行的其它任务没有任何影响，用户甚至感觉不到在进行远程的升级。

2.3 通信协议

为了能可靠的完成远程升级过程，高效、完善的通信协议是必不可少的，在本方案中我们也根据GPRS通信的特点制订了通信协议。

协议的帧格式如表1：

表1

远程升级共需要使用4条命令：

（a）查询终端当前软件的版本信息（可选）；

（b）远程升级准备(待升级程序总包数下发)；

（c）发送升级程序的数据包；

（d）查询数据包发送状态。

其中发送升级程序数据包的帧格式如表2：

表2

即把经HEX转BIN后的数据每512字节分为一段，加上2字节包号，4字节的起始地址，以及CRC校验组成一包数据。

2.4 远程升级的完整过程

经主站软件配合，一次完整的程序升级流程如下：

a).上位机软件打开准备升级的HEX文件转换为BIN格式并分包；

b).查询终端当前程序的版本信息；（可选）

c).上位机软件发送本次要升级程序的总包号，并作为远程升级的请求命令；

d).等待终端应答；

e).收到应答后，开始发送所有本次远程升级的数据包（每包之间的时间间隔应在500mS—1S之间），不必等待终端应答；

f).所有数据包发送完后，上位机发送升级完成状况查询。终端返回数据包接收状态表(表格中为1的位说明该包数据已接收并保存成功，为0说明接收或保存失败)；

g).上位机根据数据包接收状态表继续发送未保存成功的数据包，不必等待终端应答；

h).重复f—g步骤，直到终端返回所有数据包接收并保存成功。

i).终端接收完所有数据包后，检查升级时间是否到，如果升级时间到则停止喂狗，复位系统，进入引导程序中，开始程序的更新。如果设置的是数据包接收完后立即升级，则在数据包接收完后，延时30S复位系统，进入引导程序开始升级。

以上看似繁琐的过程，其实对于操作人员来说只需要完成步骤a）、b），其它步骤均由主站软件完成。测试软件的界面图4所示。

2.5 HEX文件的合并

因为在本方案中把程序分为了引导程序和应用程序，这就必然导致编译后会产会生2个HEX文件，对于生产部门来说，就意味着同一个芯片要烧写2次程序，如果大批量生产，这是无法接受的。因此我们考虑将编译后的Bootloader.hex文件和APP.hex文件合并，实际证明这是可行的。通过查阅HEX文档存储格式的相关文档，最终找到了解决办法。

经过合并后，最终就只有一个HEX文件，这样不但解决了影响生产效率的问题，同时也便于管理。对于主站软件来说，升级时只需要跳过32KB的引导程序空间从地址0x8000开始解析数据即可。HEX文件的合并过程请参阅有关HEX格式的文档，这里不再阐述。

图4 远程升级主站测试软件

3 远程升级测试结果

该远程升级方案实现后，进行了测试，如图4所示。

（1）HEX文件被分为126个包，每帧数据的发送间隔为800ms，第一次发送，126包数据有3包没有发送成功，即一次丢包率只有2.3%，一般只需重复一次即可百分百完成升级。多次测试结果基本相同，在网络状况良好的情况下，也有一次就完成升级的。

（2）一次升级所花费时间问题。这个当然跟所要升级的程序大小有关，也与网络状况有一定的关系。按照上述测试，126包（126×521 Bytes=63KB的程序）所耗时间为126×800ms+3×800ms=1.72min，即所耗时间为1.72分钟。

（3）因为在数据帧下发的过程中不需要被升级终端应答，因次可以同时对多台终端升级，这样效率更高。

（4）协议中允许一帧数据包含多个程序数据包，但是实际测试中发现每帧数据包含2个以上数据包（1024字节以上）时，丢包的概率就会增加很多。原因是数据帧太长，被分割开了，可能是GPRS通信服务器分割的也可能是网络运营商的系统分割的，目前还没有找到原因。如果能实现一帧数据中包含多个程序包，将能大大的提高程序升级的效率。

（5）远程升级的可靠性。通信过程中的数据是保存在外部Data FLASH中，并没进行程序的更新，因此即使出现通信中断，也不会影响当前运行的程序。当程序复位并运行引导程序进行更新时，整个过程是很快的，因此出现问题的概率也很小，即使出现复位等异常情况，因为没有更新成功，复位后还会继续更新，直至程序更新成功。如果保存在Data FLASH中的程序数据出现异常，更新失败，那么还会读取备份的程序恢复到更新前的状态。另外程序中也考虑多种异常情况的处理措施，确保升级过程可靠。

LPC 2022：MGLRU页面回收改进有望并入Linux 6.1内核主线

在爱尔兰都柏林举办的 LPC 2022 活动期间，我们看到了有望在 Linux 6.1 中并入主流的 Multi-Gen LRU 项目的最新进展。作为当前 Linux 内核页面回收代码的一个更好替代方案，如果 MGLRU 能够在 2022 的最后一个完整内核周期内登陆 Linux 6.1，那它也将成为年内最激动人心的创新之一。

Phoronix 指出，从 ChromeOS / Android，到台式机、工作站、甚至服务器领域，MGLRU 普遍能够在各项工作负载和各类硬件平台上提供更好的性能。

Google 的 Jesse Barnes 和 Rom Lemarchand 在昨日的 LPC 2022 活动期间指出，现有的页面回收代码总被吐槽做出了糟糕的驱逐选择。

好消息是，俩人重申了 MGLRU 有望并入 Linux 6.1 的期望。可知目前已有不少内核下游和反向移植在生产环境中使用相关代码，且基准测试成绩的前景也显得相当光明。

一旦走入主线，Google 工程师团队将致力于让 MGLRU 达到和默认安全启用的水平。

尽管在这之前，他们还需要开展各种基准测试，以确保 MGLRU 处理良好状态、且不会使现有工作负载出现性能退化。同时他们希望将 MGLRU 与 eBPF 集成，以开辟更多可能性。

最后，在今日的 LPC 2022 会议期间的 Android 小分会上，Google 公司的 Kalesh Singh 就 Android 设备上的 MGLRU 性能进行了演示。

此外 Andrew Morton 评论称，其希望在本周晚些时候将 MGLRU 补丁挪到“mm-stable”分支。如果一切顺利，我们可期待在 10 月开启的下一个 Linux 6.1 合并窗口。