1 Introduction

As the Software Defined Radio (SDR) technology has been widely used, firmware upgrades of the systems become possible. The firmware upgrade methods for existing systems are mainly on-site, but for the devices mounted on a high altitude, underground, and other rough terrain, on-site upgrades are extremely difficult, or even impossible. Meanwhile, the devices which need to be upgraded are of great quantity. For these reasons, the upgrade processes are tedious and costly. Therefore, an introduction of remote firmware upgrade mechanism to SDR based systems is of great significance. The SDR based systems are mostly composed of DSP and FPGA [1, 2], so the upgrade of DSP and FPGA is the major work for remote firmware upgrade. However, most of the existing remote upgrade mechanisms are designed for embedded systems [3, 4], and some researches only analyze the upgrade mechanisms for DSP [5, 6].

In view of existing problems in the researches, a safe, secure and reliable remote firmware upgrade mechanism designed for SDR based systems is proposed. Since DSP and FPGA are core chips in these systems, the upgrade of them is mainly discussed in this remote firmware upgrade mechanism. In this paper, the communication mechanism and upgrade package security are firstly introduced. Then the upgrade and loading procedures for DSP and FPGA are explained. At last, a suitable terminal hardware structure is illustrated.

2 Communication Mechanism and Upgrade Package Security

A sketchy system block diagram is shown in Fig. 29.1. A network based on TCP/IP protocol is used to establish a connection between the authorized work station and terminal. The upgrade packages are transmitted through Internet. By this means, the expense is reduced notably, and the communication between them is relatively in real time. During the upgrade operation, the work station is responsible for transmitting upgrade packages to terminals. When a terminal receives the upgrade packages, it upgrades the program automatically according to the upgrading procedure, and then restarts the system with the loading procedure. The upgrading and loading procedure will be explained in Sect. 29.3.

Fig. 29.1
figure 1

Framework of remote upgrade system

Full size image

In order to enhance the security of upgrade packages, an encryption with Advanced Encryption Standard (AES) [7] is used to encode the upgrade packages. Moreover, a digital signature based on SHA-1 algorithm [8] is also applied to the upgrade packages, which improves the security to a higher degree.

3 Upgrading and Loading Procedures for DSP and FPGA

In this section, the safe and reliable procedures for DSP and FPGA are discussed. In these procedures, synchronization mechanism between DSP and FPGA is established to make sure that program upgrading and loading proceed safely and sequentially. Moreover, the alternating upgrade strategy is used in the procedures. This strategy ensures the program presently running in the system is not overwritten. If an upgrade fails, the system can still work at present state. Thus, the cost of upgrading failure is reduced to lowest degree.

3.1 Upgrading Procedures

Two sets of program are prepared for DSP and FPGA. One is running in the system, and the other is of old version. The upgrading procedures for DSP and FPGA are shown in Fig. 29.2 and have two functions. The first one is to upgrade the program of old version orderly. The second one is to make sure that the program running in the system can be reloaded, when an error occurs during upgrade operation.

Fig. 29.2
figure 2

Upgrading procedures for DSP and FPGA

Full size image

The DSP upgrade task and FPGA upgrade block are designed to execute the upgrading procedures. The DSP upgrade task is mainly used to transmit FPGA upgrade program and burn the DSP upgrade program. The FPGA upgrade block is used to receive FPGA upgrade program and burn the new program to specific page according to the received command from DSP.

At the beginning of upgrading procedure, DSP checks the version of program sets and overwrites the DSP program of the old version. Then, it transmits FPGA upgrade program and upgrade page to FPGA. After transmitting finished, a timer in DSP is triggered to check whether the upgrading of FPGA is timeout. A timeout represents the failure of upgrading FPGA. In this circumstance, version information will not be updated. When system restarts, DSP and FPGA will reload the program running in the system before upgrading.

3.2 Loading Procedures

The loading procedures shown in Fig. 29.3 are designed to load DSP and FPGA program orderly and reliably. If an error occurs during upgrade process, the loading procedures can reload the program running in the system. Hardware circuits in the Fig. 29.3 mean that the functions are integrated in chips and processed automatically by hardware circuits.

Fig. 29.3
figure 3

Loading procedures for DSP and FPGA

Full size image

When DSP powers up, the hardware circuits load boot code automatically [9]. The boot code firstly finds the program of newest version and then sets the corresponding load number. The load number indicates which set of program will be loaded to DSP and FPGA. Next, the load number is transmitted to FPGA. Then the boot code waits until the configuration of FPGA completed. After detecting the completion of FPGA configuration, the boot code checks whether an error occurs in loading FPGA program. If an error occurs, the load number is altered. This means that the programs for DSP and FPGA are changed to the other set.

When FPGA powers up, the hardware circuits load the factory configuration [10]. The factory configuration is designed to select which set of program, application configuration 1 or application configuration 2, will be loaded to FPGA for proper operation. If an error occurs during loading the program, the error state bit, ERR, will be set, and the hardware circuits will load the factory configuration again. Then, the other set of program is loaded to FPGA.

4 Terminal Hardware Structure

4.1 Hardware Framework

A hardware framework designed for remote firmware upgrading is shown in Fig. 29.1. The cores of the framework are DSP and FPGA. Stratix II series of Altera, for FPGA, and C64x+ series of TI, for DSP, is used in this structure. The EPCSs are dedicated configuration series for Altera’s FPGA. The NOR flash is the storage of DSP program, and the E2PROM is used to save key configuration parameters.

4.2 Memory Sections and Function Description

The memory of EPCS, shown in Fig. 29.4, is divided into three pages: Page0, Page1 and Page2. The corresponding programs are factory configuration, application configuration 1 and application configuration 2, respectively.

Fig. 29.4
figure 4

FPGA memory sections

Full size image

When FPGA powers up or an error occurs during loading program, factory configuration will be loaded automatically. In order to enhance the stability of loading program, updating Page0 is prohibited. This setting ensures that factory configuration can be successfully loaded every time. Application configuration 1 and application configuration 2 are designed to execute proper operation of the system. In application configuration 1 and application configuration 2, the FPGA upgrade block which is shown in Fig. 29.2 is included.

As shown in Fig. 29.5, E2PROM and NOR flash are related to DSP program upgrade. Version Section 1 and Version Section 2 locate in E2PROM. These two sections store the version information of program sets. The version information is critical for remote upgrade processing. In order to avoid the information being written or erased by mistake, these sections are physically separated from program sets.

Fig. 29.5
figure 5

DSP memory sections

Full size image

There are three sections in NOR flash: Boot Section, Upgrade Section 1 and Upgrade Section 2. Boot Section stores boot code. The boot code is used to select load number and load program to DSP according to this number. Update Section 1 and Update Section 2 store the DSP program sets. The upgrade task shown in Fig. 29.2 is included in DSP program sets.

5 Conclusion

In this paper, a safe, secure and reliable remote firmware upgrade mechanism is presented to solve the existing firmware upgrade problems in SDR based systems. The synchronization mechanism makes various parts of the system upgrade safely and sequentially. The alternating upgrade strategy reduces the cost of remote firmware upgrade failure to lowest degree. In this upgrade mechanism, different operation attributes are applied to the memory sections. This setting enhances stability of the systems. The remote firmware upgrade mechanism makes the upgrade of SDR based systems much quicker and easier without the constraints of installation location. It reduces the cost of firmware upgrade effectively and can be widely utilized in SDR based systems.