TrueFFS上VxWorks应用程序的启动及动态更新

TrueFFS上VxWorks应用程序的启动及动态更新

　引 言

　　在嵌入式产品中，一般使用Flash作为应用程序代码及各种数据和参数的存储介质。尤其是NOR Flash具有 *** 作接口简单、传输效率高、芯片内执行(eXecute In Place，XIP)的特点，在电力、铁路等工业控制领域得到了广泛应用。

　　为了便于用户的使用，VxWorks *** 作系统提供了基于Flash的文件系统，即TrueFFS。TrueFFS与DosFS文件系统基本兼容，通过VxWorks提供的 *** 作接口以文件的方式实现对Flash的 *** 作。而对于用户来说，如何在自己的硬件系统上根据Flash的具体型号和使用要求实现TrueFFS系统，并在此基础上完成应用程序代码的灵活启动、更新，同时兼顾仿真调试的需求，则非常重要。

　　1 系统基本功能

　　本系统应用于铁路牵引自动化系统中，实现在电气化铁路供电系统中对相关电力设备的保护、测量和控制功能。系统基本功能框图如图1所示。核心CPU选用Freescale公司的ColdFire系列32位微控制器MCF5234。该处理器内部集成了UART、SPI、I2C、ETPU、CAN、以太网等丰富的功能模块，系统主频可达150 MHz，主要用于工业控制、智能家电等方面(尤其是电力自动化控制领域)。系统通过2路以太网接口实现与当地或远方设备的通信，维护串口用来实现对本设备的维护，采用2片16位接口的NOR Flash实现应用程序和有关参数及数据的存储。系统提供模拟量输入、数字量输入、数字量输出等接口。有关的模拟量及开关量状态信息经过对应接口采集到系统内部，经过保护算法软件的处理后，再通过数字量输出接口完成对有关设备的控制 *** 作。

　　在传统嵌入式系统中，编译好的运行态应用程序一般通过硬件调试工具(如BDM调试器)直接固化到程序Flash的指定位置，装置上电或复位后，CPU直接跳转到Flash的起始位置，从Flash中取指并开始执行。但是在VxWorks中，采用该方式不方便软件的仿真调试，需要重新固化bootrom才行。另外，由于系统要求保存较多的参数和数据，需要在2片Flash中都实现TrueFFS系统；并且为了满足动态更新程序的要求，还需要实现FTP的功能。因此，需要实现如下功能：在2片Flash上实现True-FFS；在bootrom和应用VxWorks程序上实现TrueFFS和FTP的加载；对bootrom进行改造，以实现应用VxWorks程序和调试VxWorks程序分别通过TrueFFS和TFTP的方式启动。

　　2 TrueFFS的实现及加载

　　2．1 TrueFFS的层次结构

　　如图2所示，VxWorks中TrueFFS的层次结构包括内核层、翻译层、socket层、MTD层。由于VxWorks对TrueFFS进行了优秀的层次划分和封装，用户一般不需要对上述基本层次代码进行修改。MTD层实现了对常用几种类型Flash的读、写、擦除等基本控制。如果用户选用了支持的类型，则基本不需要编写代码；而如果用户选用了特殊类型的Flash，则可以参考用例代码完成对应MTD层代码的编写。

　　2．2 MTD层代码实现

　　由于本系统中选用的2片Flash为Spansion公司的S29AL032D，因此需要编写对应的驱动代码。对于MTD层，一般向上提供MTD识别、Flash连续扇区擦除、Flash连续数据写等主要接口函数，可以不提供单独的镜像函数，系统会使用内部缺省的镜像函数。需要在2片Flash上实现TrueFFS，即每片Flash相当于一个分区，这一点在编写驱动程序时需要重点考虑。在MTD层驱动程序中，Flash的单个字节(或字)写入接口函数为重点，不同Flash类型以及不同的端口宽度都会导致该函数的实现不同。其写 *** 作流程如图3所示。

　　为了在两片Flash上实现2个文件分区，可以采用以下方式：在sysTffs．c中定义新的MTD类型，并根据实际需要定义2片Flash(即两个分区)的起始地址和长度，并根据上述定义完成TrueFFS设备基址和窗口尺寸的设置；在sysTffsInit()函数中进行2次rfaRegister() *** 作以完成2个分区的注册；在rfaRegister()中根据注册的TrueFFS设备个数设置本TrueFFS设备的设备号。在MTD层接口函数中一般都有一个Flash驱动设备的参数，可以根据该参数来获取2个TrueFFS设备的设备号，然后分别指向对应的Flash地址范围进行相应的 *** 作。

　　MTD驱动设计完成后，可以根据VxWorks提供的方式完成TrueFFS的加载。在应用程序中可以通过组件配置界面进行加载配置，而在bootrom中则需要手动修改相应的配置文件。

　　由于系统的启动需要从boottom开始，其编译的结果文件必须以二进制方式固化到程序Flash的起始位置，因此每片Flash起始的256 KB空间都预留出来，不参与TrueFFS系统的管理。这样，Flash上文件的 *** 作与bootrom启动代码的保存不存在冲突。

　　3 bootrom的改进

　　在VxWorks中，修改好的bootrom一般通过硬件调试工具固化到代码Flash中，bootrom启动后通过TFTP方式实现编译好的调试用VxWorks映像文件的下载过程，并完成该映像文件的启动。这样就可以实现基于串口或网络的应用程序调试，使用更加方便灵活。

　　为了满足系统的要求，bootrom还需要增加如下功能：支持2个Flash分区的TrueFFS加载；支持FTP功能；支持从TrueFFS加载及启动应用程序，以及从TFTP网络方式加载及启动调试态VxWorks映像文件两种方式，以保证系统即使在现场运行过程中，一旦发现问题，也能够方便地进行仿真调试；支持Flash的格式化及True-FFS的初始化功能，一旦文件系统异常后，可以通过该功能进行TrueFFS的彻底重构。由于boottom的主要工作在bootconfig．c文件中实现，因此上述改进工作也主要在该文件中进行。

　　还需要完成以下工作：在对应配置文件中加入IN-CLUDE_TFFS和INCLUDE_FTP_SERVER的定义，从而实现系统对TrueFFS和FTP功能的加载；对bootloader函数进行修改，使其不支持基于TrueFFS的应用程序启动，当需要调试时通过网络方式加载和启动；增加一个类似于bootloader的功能函数，可以以此函数为模版进行修改，完成TrueFFS功能的初始化和加载过程，以及基本网络功能和FTP功能的加载，同时在程序Flash文件分区中存在应用程序文件的前提下，实现该应用程序的加载和启动功能；增加2片Flash的格式化和TrueFFS的初始化功能函数。

　　对bootCmdLoop任务执行流程进行调整，改进后的流程如图4所示。

　　在bootCmdLoop进入超级终端界面循环 *** 作过程后，可以通过相关命令完成基于网络方式的调试态VxWorks映像文件的加载和启动，也可以根据实际需要增加Flash格式化、自动进入超级终端界面标志命令设置、软件复位等功能。经过上述改进，可以实现bootrom上运行态应用程序及调试态VxWorks映像文件的灵活加载和启动，不仅避免了现场运行系统为进行调试而重新写入bootrom的问题，而且方便应用程序的动态更新。

　　4 应用程序的动态更新

　　为了便于产品的维护和升级，本系统需要支持基于FTP的应用程序动态更新，而VxWorks提供了各种类型应用程序的加载启动方式。由于应用程序最终在动态RAM中执行，因此在TrueFFS和FTP功能具备的前提下，实现应用程序的动态更新非常方便。

　　经过改造后，bootrom和最终应用程序中都实现了TrueFFS和FTP功能，因此在bootrom和最终应用程序执行时都可以完成应用程序加载。另外，由于具备了bootrom中更新应用程序的功能，即使由于应用程序异常导致无法运行，复位后重新进入bootrom仍然可以进行新程序的更新，从而增强了系统的健壮性。

　　需要注意的是，通过TrueFFS方式加载启动的最终应用程序也是default类型的，而不是rom类型的。如果下载到文件系统中的应用程序是rom类型，则会导致bootrom无法成功加载该文件，因为其实现方式与仿真调试过程基本类似。

　　结 语

　　经过测试，采用上述实现方案后，系统运行稳定。通过FTP工具，可以灵活地对2片Flash上文件分区中的文件进行读写 *** 作，2 MB左右的应用程序文件可在30 s内下载到Flash中。整个系统的启动过程稳定可靠，对于2 MB左右的应用程序，从装置上电到bootrom启动，再到应用程序正常开始运行，基本可在十几秒内完成。本方案对于基于VxWorks系统的嵌入式产品有一定的借鉴意义。