Application of Railway Traction Automation System Based on TrueFFS

Introduction

In embedded products, Flash is generally used as the storage medium for application code and various data and parameters. In particular, NOR Flash has the characteristics of simple operation interface, high transmission efficiency, and on-chip execution (eXecute In Place, XIP), and has been widely used in industrial control fields such as power and railways.

In order to facilitate user use, the VxWorks operating system provides a Flash-based file system, namely TrueFFS. TrueFFS is basically compatible with the DosFS file system, and the operation of Flash is implemented in the form of files through the operation interface provided by VxWorks. For users, it is very important to implement the TrueFFS system on their own hardware system according to the specific model and usage requirements of Flash, and on this basis, complete the flexible startup and update of the application code, while taking into account the needs of simulation debugging.

1 Basic functions of the system

This system is used in the railway traction automation system to realize the protection, measurement and control functions of related power equipment in the electrified railway power supply system. The basic functional block diagram of the system is shown in Figure 1. The core CPU uses the ColdFire series 32-bit microcontroller MCF5234 of Freescale. The processor integrates a variety of functional modules such as UART, SPI, I2C, ETPU, CAN, Ethernet, etc. The system frequency can reach 150 MHz and is mainly used in industrial control, smart home appliances, etc. (especially in the field of power automation control). The system communicates with local or remote devices through 2 Ethernet interfaces. The maintenance serial port is used to maintain the equipment. Two 16-bit NOR Flashes are used to store application programs and related parameters and data. The system provides interfaces such as analog input, digital input, and digital output. The relevant analog and switch status information is collected into the system through the corresponding interface. After being processed by the protection algorithm software, the control operation of the relevant equipment is completed through the digital output interface. In traditional embedded systems, compiled running applications are generally directly fixed to the specified location of the program Flash through hardware debugging tools (such as BDM debugger). After the device is powered on or reset, the CPU directly jumps to the starting position of the Flash, fetches instructions from the Flash and starts execution. However, in VxWorks, this method is not convenient for software simulation debugging, and the bootrom needs to be re-fixed. In addition, since the system requires the storage of more parameters and data, the TrueFFS system needs to be implemented in both Flashes; and in order to meet the requirements of dynamic program updates, the FTP function also needs to be implemented. Therefore, the following functions need to be implemented: implement True-FFS on two Flashes; implement the loading of TrueFFS and FTP on the bootrom and the application VxWorks program; modify the bootrom to enable the application VxWorks program and the debugging VxWorks program to be started through TrueFFS and TFTP respectively. 2 Implementation and loading of TrueFFS 2.1 Hierarchical structure of TrueFFS As shown in Figure 2, the hierarchical structure of TrueFFS in VxWorks includes kernel layer, translation layer, socket layer, and MTD layer. Since VxWorks has made excellent hierarchical division and encapsulation of TrueFFS, users generally do not need to modify the above basic hierarchical codes. The MTD layer implements basic control of reading, writing, and erasing of several commonly used types of Flash. If the user chooses a supported type, there is basically no need to write code; if the user chooses a special type of Flash, the corresponding MTD layer code can be written by referring to the use case code. 2.2 MTD layer code implementation Since the two Flash chips selected in this system are Spansion's S29AL032D, the corresponding driver code needs to be written. For the MTD layer, the main interface functions such as MTD identification, Flash continuous sector erasing, and Flash continuous data writing are generally provided to the upper layer. A separate mirror function may not be provided, and the system will use the internal default mirror function. It is necessary to implement TrueFFS on two Flashes, that is, each Flash is equivalent to a partition, which needs to be considered when writing the driver. In the MTD layer driver, the single byte (or word) write interface function of Flash is the focus. Different Flash types and different port widths will lead to different implementations of this function. The write operation process is shown in Figure 3. [page] In order to implement two file partitions on two Flashes, the following methods can be used: define a new MTD type in sysTffs.c, and define the starting address and length of two Flashes (that is, two partitions) according to actual needs, and complete the setting of the TrueFFS device base address and window size according to the above definition; perform two rfaRegister() operations in the sysTffsInit() function to complete the registration of two partitions; set the device number of this TrueFFS device in rfaRegister() according to the number of registered TrueFFS devices. In the MTD layer interface function, there is usually a parameter for the Flash driver device. The device numbers of the two TrueFFS devices can be obtained based on the parameter, and then the corresponding Flash address ranges can be pointed to for corresponding operations. After the MTD driver design is completed, the TrueFFS can be loaded according to the method provided by VxWorks. In the application, the loading configuration can be performed through the component configuration interface, while in the bootrom, the corresponding configuration file needs to be manually modified. Since the system startup needs to start from the boottom, the compiled result file must be solidified in binary to the starting position of the program Flash, so the 256 KB space at the beginning of each Flash is reserved and does not participate in the management of the TrueFFS system. In this way, there is no conflict between the operation of the file on the Flash and the preservation of the bootrom startup code.

3 Improvement of bootrom

In VxWorks, the modified bootrom is generally fixed to the code Flash through the hardware debugging tool. After bootrom is started, the compiled debugging VxWorks image file is downloaded through TFTP and the image file is started. In this way, application debugging based on serial port or network can be realized, which is more convenient and flexible to use.

In order to meet the requirements of the system, bootrom also needs to add the following functions: support TrueFFS loading of 2 Flash partitions; support FTP function; support loading and starting applications from TrueFFS, and loading and starting debugging VxWorks image files from TFTP network, so as to ensure that even if the system is running on site, once a problem is found, it can be conveniently simulated and debugged; support Flash formatting and True-FFS initialization function. Once the file system is abnormal, TrueFFS can be completely reconstructed through this function. Since the main work of boottom is implemented in the bootconfig.c file, the above improvements are also mainly carried out in this file.

The following tasks also need to be completed: add the definitions of IN-CLUDE_TFFS and INCLUDE_FTP_SERVER to the corresponding configuration files, so as to enable the system to load the TrueFFS and FTP functions; modify the bootloader function so that it does not support the startup of applications based on TrueFFS, and loads and starts through the network when debugging is required; add a function function similar to the bootloader, which can be used as a template for modification to complete the initialization and loading process of the TrueFFS function, as well as the loading of basic network functions and FTP functions, and at the same time, under the premise that the application file exists in the program Flash file partition, realize the loading and starting function of the application; add the formatting of two Flash chips and the initialization function of TrueFFS.

Adjust the execution process of the bootCmdLoop task, and the improved process is shown in Figure 4. After the bootCmdLoop enters the hyperterminal interface loop operation process, the loading and starting of the debugging state VxWorks image file based on the network can be completed through relevant commands, and the functions of Flash formatting, automatic entry into the hyperterminal interface flag command setting, software reset, etc. can also be added according to actual needs. With the above improvements, the flexible loading and starting of the running application and the debugging VxWorks image file on the bootrom can be realized, which not only avoids the problem of rewriting the bootrom for debugging in the field running system, but also facilitates the dynamic update of the application. 4 Dynamic update of application In order to facilitate product maintenance and upgrade, this system needs to support dynamic update of application based on FTP, and VxWorks provides various types of application loading and starting methods. Since the application is finally executed in the dynamic RAM, it is very convenient to realize the dynamic update of the application under the premise of TrueFFS and FTP functions. After the transformation, TrueFFS and FTP functions are implemented in both the bootrom and the final application, so the application can be loaded when the bootrom and the final application are executed. In addition, since the function of updating the application in the bootrom is available, even if the application cannot run due to abnormality, the new program can still be updated by re-entering the bootrom after reset, thereby enhancing the robustness of the system. It should be noted that the final application loaded and started by TrueFFS is also of the default type, not the rom type. If the application downloaded to the file system is of the rom type, the bootrom will fail to load the file successfully, because its implementation method is basically similar to the simulation debugging process.

Conclusion

After testing, the system runs stably after adopting the above implementation scheme. Through the FTP tool, the files in the file partitions on the two Flash chips can be flexibly read and written. The application file of about 2 MB can be downloaded to the Flash within 30 seconds. The startup process of the entire system is stable and reliable. For an application of about 2 MB, from the device power-on to the bootrom startup, and then to the normal start of the application, it can basically be completed within a dozen seconds. This solution has certain reference significance for embedded products based on the VxWorks system.