An FPGA+DSP-Based On-Orbit Software Updating Architecture and Strategy for Satellite Payload Control Systems

Abstract

This paper presents an architecture and strategy for on-orbit software updating of satellite payload control systems, based on a tightly coupled DSP and FPGA design. The architecture achieves tight coupling between the DSP and FPGA via the XINTF interface, integrating the DSP program and data into the FPGA bitstream. This enables synchronous updating of both chips with a single software package, significantly reducing both uplink data volume and update time. The system features a dual-flash redundant boot design and a mutual supervision mechanism between the DSP and FPGA, enabling cross-monitoring and autonomous reset, thereby significantly enhancing the system’s fault tolerance and reliability in orbit. Experimental results demonstrate a substantial improvement in fault recovery, with the weighted mean recovery time reduced from 27.09 s to 1.56 s, a relative improvement of 94.25% compared to conventional methods. Ground-based environmental tests confirm the system’s stability and engineering viability under extreme space conditions.

1. Introduction

With the continuous advancement of human science, technology, and civilization, humanity’s pace of exploration has gradually expanded into outer space, with satellites serving as one of the most important mediums for space exploration. Since the launch of the first artificial Earth satellite, thousands of satellites have been deployed, supporting a wide range of applications including communication, deep space exploration, agriculture, military missions, meteorological monitoring, and geological surveying, while continuing to expand into even more domains [1,2,3,4,5,6].

As the central control unit of a satellite payload, the payload control system manages nearly all external devices and sensors [7]. Any malfunction or anomaly in the software running on it may directly affect the efficiency and effectiveness of mission execution [8]. Therefore, the payload control system is required to meet extremely high standards of reliability and on-orbit maintainability, while also needing to satisfy strict constraints on size, weight, and power consumption [9]. In recent years, the demand for software updating in satellite missions has increased significantly. However, traditional on-orbit software (developed with Texas Instruments Code Composer Studio 12.7.1 and Xilinx Vivado 2019.1) updating strategies often rely on additional circuitry. Although such additional circuitry may achieve intended functions, it also increases system complexity and hardware costs, ultimately reducing the stability and reliability of the system. Moreover, single-processor architectures in satellites are becoming unable to meet growing functional and performance requirements when executing complex on-orbit missions [10]. This challenge is further amplified by the emergence of advanced control algorithms for satellite systems, including adaptive control strategies, fault-tolerant control schemes, and machine learning-based intelligent control approaches [11,12,13]. These sophisticated algorithms demand computing platforms with enhanced reliability, flexible reconfigurability, and robust autonomous fault recovery mechanisms—capabilities that traditional architectures often lack. To enhance fault tolerance, aerospace systems have traditionally employed redundant processors (e.g., Triple Modular Redundancy, TMR), but such approaches lead to substantial increases in hardware resources and power consumption. Thus, there is a pressing need for a control system architecture capable of achieving high reliability and autonomous fault tolerance without introducing excessive hardware complexity.

A dual-processor architecture combining a DSP (Digital Signal Processor) and FPGA (Field-Programmable Gate Array) provides an effective solution [14,15]. FPGAs offer abundant programmable logic resources and high-speed parallel processing capabilities, while DSPs excel in complex algorithm execution and process control, making them functionally complementary when integrated into a single system. Numerous relevant studies have been conducted. For example, Hao Yuehan et al. from Beijing Research Institute of Telemetry designed a laser communication payload system based on an FPGA+DSP architecture, which acquired sensor data and performed real-time fault diagnosis, achieving a more compact and cost-effective onboard device compared with traditional platforms [16]. Hao Yilong et al. designed a servo control system based on DSP and FPGA, where the DSP serves as the main control chip for internal communication control and algorithms, and the FPGA acts as an auxiliary chip for external interface control. The combination of the two enhances the rapid expandability of the servo controller, reduces the size of the hardware circuit, and improves the system’s multi-signal processing capability [17]. Ren Hongxuan et al. proposed an approach that integrates DSP and FPGA for on-orbit maintenance and software updating [14]. Their method reduced hardware redundancy while simultaneously enabling autonomous maintenance and software updating capabilities, thereby significantly improving system robustness. These studies indicate that applying DSP+FPGA collaboration in satellite payload control systems (hereinafter called ‘the SPC systems’) is an important trend for enhancing both performance and reliability [18,19,20].

To differentiate our contribution from prior research, we categorize related FPGA+DSP update schemes as follows. Traditional schemes maintain separate storage and update paths for the FPGA bitstream and the DSP program, requiring independent update procedures and lacking integrated fault recovery mechanisms [9,17]. Existing cooperative schemes (e.g., [17]) introduce elements of supervision and reconfiguration but often retain separate program images or implement only unidirectional monitoring. In contrast, the architecture and strategy proposed in this work are distinguished by three-fold integration: (1) the physical integration of the DSP program into the FPGA bitstream, enabling single-package synchronous updates; (2) the functional integration of a bidirectional cross-supervision and reset mechanism between the DSP and FPGA for rapid fault containment; and (3) the architectural integration of a dual-flash redundant bootloader that leverages this tight coupling for autonomous recovery from storage faults. This integration is designed to minimize the Mean Recovery Time (MRT) for a range of common on-orbit faults.

Motivated by the challenges in on-orbit software updating for the SPC systems, this paper proposes a DSP+FPGA-based control system architecture and an on-orbit software updating strategy, and implements a prototype system for experimental verification. The main contributions of this paper are as follows:

(a)

A DSP+FPGA-based control system architecture and the corresponding on-orbit software updating strategy are proposed.

(b)

A DSP+FPGA-based on-orbit software updating strategy is proposed, which enables synchronous updates of both the DSP program (developed with Texas Instruments Code Composer Studio 12.7.1) and FPGA bitstream (developed with Xilinx Vivado 2019.1), thereby improving the efficiency of software updating in the SPC systems.

(c)

Based on (a) and (b), a prototype system is designed and implemented. Extensive ground-based environmental tests and functional tests are conducted, verifying the feasibility and reliability of the proposed on-orbit software updating strategy.

2. Review on SPC System Architectures and Positioning of This Work

The design of SPC systems has continuously evolved with the advancement of space mission requirements. Its core objective is to achieve an optimal balance of functionality, performance, and maintainability under stringent constraints of reliability, power consumption, size, and weight. In recent years, a diverse range of technological pathways has emerged, from traditional centralized architectures to novel concepts like software-defined satellites and “space-based supercomputing.” This section aims to outline the characteristics of mainstream architectures and clearly position the innovative value and technical contribution of the DSP+FPGA architecture proposed in this paper.

2.1. Comparative Analysis of Mainstream Satellite Payload Control Architectures

As shown in

Table 1. Comparative analysis of mainstream SPC system architectures.

Architecture Type	Computing Core	Advantages	Disadvantages	Typical Scenarios	Related Work
Centralized + Distributed	CPU + multiple RTUs via 1553B/CAN buses.	High reliability via isolation; Proven maturity.	High SWaP; Poor flexibility; Complex integration.	Large GEO satellites; Deep space probes.	[21,22]
CPU + FPGA/SoC Integrated	SoC or CPU + FPGA tightly coupled.	Low SWaP; Fast development; Suitable for mass production.	Single-point failure risk; Limited processing power for demanding tasks.	Micro/nano-sats; CubeSats; LEO constellations.	[23,24]
Heterogeneous Computing	CPU + FPGA + AI Accelerator (e.g., GPU/NPU).	Superior real-time processing; Supports on-orbit AI.	Highest complexity; High power/cost; Challenging programming/scheduling.	Intelligent remote sensing; Real-time reconnaissance.	[25,26]
Software-Defined Satellite	Core based on reconfigurable FPGA/APSoC.	Maximum mission flexibility; Extended satellite value/lifetime.	Lower maturity; Reliability/security challenges in dynamic reconfiguration.	Tech demonstration; Agile response missions.	[27,28,29]
Space-Based Supercomputing	Cluster of heterogeneous computing satellites via inter-satellite links.	Transforms data flow (“data in, information out”); Enables new applications.	Conceptual/early stage; Major engineering hurdles; Extreme cost/risk.	Future mega-constellations; Space-based network nodes.	[30,31,32]

, current SPC systems exhibit five typical architectural paradigms, each with distinct advantages, disadvantages, and applicable scenarios.

2.2. Positioning of the Proposed DSP+FPGA Architecture

The SPC system architecture based on tightly coupled DSP and FPGA proposed in this paper can be viewed, from a technological lineage perspective, as a highly reliable, engineering-oriented implementation in the evolutionary path from Type 2 (CPU + FPGA/SoC Highly Integrated Unified Architecture) towards Type 3 (Heterogeneous Computing Architecture). It does not pursue extreme stacking of heterogeneous computing power but rather achieves a critical engineering balance between integration, reliability, updatability, and real-time processing capability, specifically tailored for high-reliability, on-orbit maintainable complex payload control scenarios.

• Compared with other architectures, the core innovation and differentiated advantages of the proposed architecture are as follows:
  • Compared to Traditional Distributed Architectures (Type 1): This architecture achieves tight coupling and memory sharing between the DSP and FPGA via the XINTF interface, greatly simplifying hardware interconnects. Furthermore, its single-package synchronous update mechanism provides on-orbit flexibility and maintenance efficiency unattainable by traditional architectures.
  • Compared to Similar Integrated Architectures (Type 2): This architecture goes beyond mere physical integration by introducing a system-level mutual supervision and autonomous recovery mechanism. The DSP and FPGA are not in a master-slave relationship but act as cross-watchdogs for each other, capable of detecting and resetting faulty units, significantly mitigating the single-point failure risk inherent in high integration.
  • Compared to Cutting-Edge Heterogeneous/Software-Defined Architectures (Types 3, 4): While this architecture lacks dynamic reconfiguration or integrated dedicated AI accelerators, its design philosophy is highly aligned: achieving optimal task matching through the cooperation of a dedicated processor (DSP) and programmable logic (FPGA). This work provides a thoroughly ground-validated, highly reliable updatable heterogeneous computing core, laying a solid hardware and software maintenance foundation for future integration of more complex control algorithms or lightweight intelligent processing functions.
  • Regarding Support for Advanced Control Strategies: The advanced control methods mentioned by the reviewers (e.g., the event-triggered MPC in reference [7]) typically impose high demands on processor real-time computing capability and algorithm updatability. The FPGA in the proposed architecture can provide deterministic, ultra-low latency processing to meet the real-time requirements of algorithms like thermal control and motor control, while the synchronous update mechanism ensures that advanced control algorithms can be deployed and iterated on-orbit safely.

3. System Structure

The architecture of the proposed SPC system is illustrated as Figure 1. The control system consists of a DSP chip and an FPGA chip, which are interconnected through an external interface (XINTF) to form a shared memory space, thereby achieving a tightly coupled relationship. The FPGA is configured with two independent flash memory chips (Flash 1 and Flash 2), which store both the FPGA configuration bitstreams and the DSP program and data. A magnetic latching relay is employed to control the chip-select signals of the two flash memories.

The satellite platform (host computer) transmits on-orbit software updating data to the SPC system via a high-speed serial interface, while system-level control is achieved through a Controller Area Network (CAN) bus. Within the SPC system, the reset ports of the DSP and FPGA are connected to each other, allowing each device to reset the other, thereby enabling mutual supervision and recovery.

3.1. Architecture of the SPC System—Synchronous Updating and Mutual Supervision Strategy Based on DSP+FPGA

As shown in Figure 1, the SPC system receives software updating instructions and data from the satellite platform through software updating interfaces (CAN bus and high-speed serial interface), responds to the software updating instructions, and stores the software updating packages into the corresponding flash memory. After power-up, the FPGA loads and executes its bitstream stored in the flash memory. The program and data of the DSP are stored in binary format within the BRAM of the FPGA. Once powered on, the DSP automatically loads its program and data from the FPGA BRAM.

The DSP and FPGA chips are designed to mutually monitor each other’s operational status. After the DSP successfully powers up and runs, it periodically sends watchdog signals to the FPGA to inform the FPGA its running status. If the FPGA fails to detect these watchdog signals, it concludes that the DSP is not running properly and issues a reset signal to reinitialize the DSP. The DSP supports two running modes: Microprocessor (MP) mode and Microcontroller (MC) mode, controlled via its MP/MC interface. When the FPGA powers up successfully, it switches the DSP into MP mode, in which the DSP loads program and data from the FPGA BRAM via the XINTF interface. Conversely, if the FPGA fails to power up properly, the DSP remains in MC mode, booting from its internal OTP ROM. In this case, the DSP issues a reset signal to reinitialize the FPGA.

The software data flash memory for the FPGA is managed by a magnetic latching relay under DSP control. A key feature of the magnetic latching relay is that its selection state is preserved even when the system is powered off, ensuring a deterministic and controllable FPGA startup status.

Thus, the proposed DSP+FPGA-based SPC system achieves both synchronous on-orbit software updating and mutual supervision. This design reduces circuit redundancy while simplifying the software updating process in this dual-chip architecture, thereby improving the reliability and success rate of on-orbit software updating for the SPC system.

3.2. Communication and Data Exchange Approach Between the DSP and FPGA

The DSP and FPGA achieve high-speed data communication via the XINTF interface, which maps a dual-port memory block (BRAM) inside the FPGA as external memory for the DSP. This shared memory is divided into 2 regions accessible to the DSP, including a code region and a data region:

• Code Region: Stores the executable program code for the DSP. After power-up and reset, the DSP can directly fetch and execute instructions from this region, effectively using the FPGA’s BRAM as its external memory.
• Data Region: Serves as the communication buffer for exchanging commands, sensor data, and status flags between the DSP and FPGA. This region is further subdivided into different functional segments at predefined addresses, with each address or address block representing a specific data or command channel.

The data exchange follows a handshake-like strategy. When the FPGA needs to send new data or commands to the DSP, it writes the content into the corresponding address of the data region and sets a “data ready” flag to inform the DSP. The DSP’s main program periodically checks the flag registers. Once a flag is set, the DSP immediately reads the corresponding data, processes it, and then clears the flag. Similarly, when the DSP needs to send results or commands back to the FPGA, it writes the data into another predefined address of the data region, sets the notification flag. When the FPGA detects the flag, it reads the data and clears it accordingly.

Through this strategy of shared BRAM and flag clearance/setting, decoupled communication between the DSP and FPGA is achieved: both parties can asynchronously read and write the shared memory while completing handshakes via flags. This strategy ensures the timeliness and reliability of data exchange between the DSP and FPGA.

3.3. Communication Structure Between the Payload System, Satellite Platform, and Ground Station

As illustrated in Figure 2, the software updating data for the SPC system is first generated on a ground computer and then transmitted to the ground station, which communicates with the satellite. The ground station transmits the updating package to the satellite system via microwave links in an end-to-end manner. Subsequently, the satellite platform transmits the updating data through the software updating interface to the payload system, thereby completing the on-orbit software updating of the SPC system.

During the on-orbit software updating process of the DSP+FPGA dual-chip architecture, only a single software updating package needs to be transmitted. This enables synchronous updating of both chips in one step, significantly reducing the complexity of the on-orbit software updating process for the SPC system.

4. Algorithms and Procedures

4.1. Dual-Flash Redundant Boot Design

To address the risk of program corruption in space (e.g., single-event upsets caused by cosmic radiation), the proposed system adopts a dual-flash redundant boot strategy. As shown in Figure 1, two independent flash chips (Flash 1 and Flash 2) are deployed to store both the FPGA bitstreams, DSP code and data. The chip-select signals of the two flash memories are controlled by a magnetic latching relay. By default, after power-up, Flash 1 is selected as the active memory. The FPGA first loads its bitstream from Flash 1 to complete self-configuration, while the DSP powers up in Microcontroller (MC) mode and executes a monitoring program stored in its internal OTP ROM.

Once the FPGA successfully runs from Flash 1, it drives the DSP’s MP/MC mode-select pin high to MP and generates a reset signal to the DSP. After reset, the DSP switches into Microprocessor (MP) mode, fetching its program from the code region of the FPGA BRAM through the XINTF interface.

Shown as the DSP XINTF address space in Figure 3, before the startup, the DSP program code has been stored in the code region of the FPGA BRAM, with this region mapped to Zone 7 of the XINTF interface (corresponding to the address range 0x3FC000–0x3FFFFF). After startup and reset, the DSP’s program counter (PC) points to the reset vector at address 0x3FFFC0, from which it begins fetching and executing instructions at the address indicated by this vector. Consequently, the DSP successfully boots from the external memory space provided by the FPGA, executing the program code stored in Flash 1.

As summarized in Figure 4, the DSP boot sequence proceeds as follows:

• Default Power-up: The magnetic latching relay defaults to select Flash 1. After power-up, the FPGA reads its bitstream from Flash 1 to complete initialization. The DSP powers up in MC mode, executing the internal OTP ROM program.
• Switch to MP Mode: Once the FPGA initialization is completed, it sets the DSP’s mode pin to MP and issues a reset signal. The DSP then reboots in MP mode and begins instruction fetches via the XINTF interface.
• Execute Application Program: The DSP accesses the code region mapped to XINTF Zone7, fetches the reset vector at 0x3FFFC0, and jumps to the program entry point, begins to execute its main program.

This process ensures that under normal conditions, the system can boot the FPGA program from Flash 1. Considering the potential Flash 1 failures (e.g., data corruption or initialization errors), a flash-switch strategy is implemented. If the FPGA fails to complete initialization from Flash 1 during power-up, the DSP’s OTP ROM program will run a flash-switch sequence after a predefined timeout. Specifically, the DSP controls the magnetic latching relay to deselect Flash 1 and switch to Flash 2, then issues an FPGA reset signal so that the FPGA reads its bitstream from Flash 2. The power-up sequence is then repeated. If the FPGA bitstream stored in Flash 2 is correct, the system successfully powers up from this backup flash.

This entire procedure is completed autonomously without ground station’s intervention, significantly improving the SPC system’s on-orbit power-up reliability. The dual-flash redundant design leverages the DSP OTP ROM bootloader and the FPGA’s reconfiguration capability to achieve a safe power-up process for the SPC system: if the default flash fails, the system automatically switches to the backup flash, preventing a single-point memory fault’s incapacitating the system. This dual-flash auto-switch strategy resembles dual-processor redundancy in principle but achieves robustness at lower cost by employing redundant flash memories instead of copying processors.

4.2. On-Orbit Software Updating Process of the SPC System

During satellite missions, it is often necessary to update the SPC system software (developed with Texas Instruments Code Composer Studio 12.7.1 and Xilinx Vivado 2019.1) to fix potential defects or to accommodate new requirements. In conventional architectures, the DSP and FPGA programme are stored in separate devices, requiring an independent updating process for DSP and FPGA software, which considerably increases the complexity of the process. In contrast, this work integrates the DSP program into the FPGA bitstream, thereby enabling a single package to update the software for both chips synchronously.

As shown in Figure 5, the satellite platform transmits updating instructions and software data to the SPC system via the CAN bus and the asynchronous serial interface, respectively. The SPC system buffers the received data locally and stores it in the corresponding FPGA flash memory, where it can be accessed during subsequent system power-up. When power-up, the FPGA loads its bitsream and begins running from the flash memory, while the DSP reads its program and data via the XINTF interface and exchanges information with the FPGA.

In this architecture, both the DSP program and data are stored as part of the FPGA bitstream, which are stored in the FPGA BRAM and mapped to the DSP through the XINTF interface, as also illustrated in Figure 5.

The flowchart of the synchronous on-orbit software updating strategy is presented in Figure 6.

When the SPC system receives an on-orbit updating instruction from the satellite platform, it prepares to accept the incoming software data. The software data is transmitted via the software updating interface and then stored in the FPGA flash memory. After the completion of data transmission, the satellite platform sends a reset instruction. The FPGA then resets, reads the bitstream from the flash memory, sets the DSP into Microprocessor (MP) mode, and waits for the DSP watchdog signal. If the watchdog signal is not detected, this indicates that the DSP failed to power up correctly, and then the FPGA resets the DSP. Conversely, if the DSP is not properly configured into MP mode by the FPGA, it defaults to run from its internal OTP ROM, where a flash-switch program will issue an FPGA reset signal after a predefined timeout and restart the power-up process until the entire system runs correctly.

The software update process for the SPC system is implemented as a finite state machine (FSM) with well-defined states and transitions. Algorithm 1 details this synchronous on-orbit update state machine.

Algorithm 1 On-orbit synchronous update state machine

1: Initial State: IDLE   2: $$   3: On update command received from satellite platform:   4: Transition to RECEIVING state   5: Parse command to extract target Flash identifier (non-active Flash)   6: Receive data packets via high-speed serial interface   7: Validate packet sequence numbers and CRC   8: if transmission error detected then   9:       Request retransmission 10:       Remain in RECEIVING state 11: else 12:       Transition to VERIFYING state 13: end if 14: In VERIFYING state: 15: Compute overall CRC32 of received data 16: Compare with CRC value in packet 17: if CRC mismatch then 18:       Report error to satellite platform 19:       Transition to IDLE state 20: else 21:       Transition to PROGRAMMING state 22: end if 23: In PROGRAMMING state: 24: Disable access to target Flash (if required) 25: Program integrated image to target Flash via FPGA configuration interface 26: Verify Flash content (e.g., readback verification) 27: Transition to WAIT_REBOOT state 28: In WAIT_REBOOT state: 29: Wait for system restart command from satellite platform 30: if restart command received then 31:       DSP controls magnetic latching relay to switch to updated Flash 32:       DSP triggers system reset 33:       System boots from new Flash, completing update 34:       Transition to IDLE state 35: end if

The state machine defined in Algorithm 1 ensures a controlled and reliable update process. The critical design considerations include: (1) always updating the non-active Flash to maintain a functional backup, (2) comprehensive data validation at multiple stages to prevent corrupted updates, and (3) explicit ground confirmation before activating the updated image. This approach minimizes the risk of rendering the system inoperable during the update process, which is particularly crucial for on-orbit operations where physical access is impossible.

Through this design, the DSP and FPGA achieve synchronous software updating and mutual supervision: each device monitors the other’s operational status and performs reset actions when the counterpart fails to power up correctly. This strategy not only simplifies the on-orbit updating process but also enhances system reliability and robustness.

4.3. Integrated Software Package Construction Flow and Structure

To implement the single-package synchronous update strategy, the construction of the integrated software package that merges the DSP program and data into the FPGA bitstream is critical. This subsection details the toolchain workflow and the structure of the final update package.

The structure of the software update package transmitted from the ground station is defined in

Table 2. Software update packet format.

No.	Field Name	Length (Bytes)	Description	Value/Remarks
1	Sync Header	2	Frame synchronization header	0xFBFB
2	Packet ID	4	Packet identifier	0x00000000∼0x000037E2
				(Incremental per actual packet)
3	Total Packet Count	4	Total number of software data packets	0x000037E3 (With a total size of 12,047,189 bytes)
4	Frame Length	2	Size of each small data packet	856 (including 14-byte header)
				Protocol supports 0x0000∼0xFFFF
5	Payload Data	842	Main software update data	-
6	Checksum	2	Data integrity check	Calculated from Packet ID to end of Payload Data
				Unsigned single-byte accumulation, initial value 0x0000
				Overflow wraps to lower 2 bytes, high byte first
				Range: 0x0000∼0xFFFF

. The package begins with a 2-byte synchronization header (0xFBFB), followed by fields for packet identification, total packet count, and frame length (which is fixed at 856 bytes, including the 14-byte protocol header). The 842-byte payload field carries the integrated FPGA bitstream containing the embedded DSP image. Data integrity is ensured by a 2-byte checksum calculated using an unsigned single-byte accumulation method over the preceding 852 bytes.

In the proposed SPC system, the Block Memory Generator (BMG) within the FPGA is configured to create two Block RAMs (BRAMs) with sizes of 8 K × 16 bits and 4 K × 16 bits, respectively. These BRAMs are mapped to specific address ranges within the DSP’s external memory space (XINTF). Specifically, the 8K BRAM is mapped to the Zone 6 address space starting from 0x100000 for data storage, and the 4K BRAM is mapped to the Zone 7 address space starting from 0x3FC000 for program code. These memory mappings are consistent with the DSP memory allocation shown in

Table 3. DSP memory allocation in linker command file.

Page	Memory Block	Origin (Hex)	Length (Hex)
PAGE 0 (Program)	ZONE0	0x002000	0x002000
	ZONE1	0x004000	0x002000
	RAML0	0x008000	0x002000
	ZONE2	0x080000	0x080000
	BEGIN	0x100000	0x000002
	ZONE6 (Code)	0x100002	0x007FFE
	OTP	0x3D7800	0x000800
	FLASHJ	0x3D8000	0x002000
	FLASHI	0x3DA000	0x002000
	FLASHH	0x3DC000	0x004000
	FLASHG	0x3E0000	0x004000
	FLASHF	0x3E4000	0x004000
	FLASHE	0x3E8000	0x004000
	FLASHD	0x3EC000	0x004000
	FLASHC	0x3F0000	0x004000
	FLASHA	0x3F6000	0x001F80
	CSM_RSVD	0x3F7F80	0x000076
	CSM_PWL	0x3F7FF8	0x000008
	RAMH0	0x3F8000	0x002000
	ZONE7	0x3FC000	0x003000
	ROM	0x3FF000	0x000FC0
	RESET	0x3FFFC0	0x000002
	VECTORS	0x3FFFC2	0x00003E
PAGE 1 (Data)	RAMM0	0x000040	0x000800
	ZONE6 (Data)	0x106000	0x00A000

, where ZONE6 and ZONE7 are allocated in PAGE 0 for program memory.

Prior to the system’s initial operation, these FPGA BRAMs contain no valid DSP program or data. The process to embed the DSP image into the FPGA configuration is as follows: First, the DSP application is developed and debugged using the TI Code Composer Studio (CCS) integrated development environment with the memory allocation defined in the linker command file (Table 3). After the DSP runs correctly, the Memory Browser tool within CCS is utilized to inspect and export the contents of the specific memory address ranges (0x100000-0x107FFF and 0x3FC000-0x3FFFFF). The exported binary data is then converted into the COE file format, which is a standard memory initialization file readable by Xilinx FPGA design tools.

Subsequently, within the Xilinx Vivado design suite, these COE files are assigned as the initialization content for the corresponding BMG IP cores in the FPGA project. This step effectively hard-codes the DSP program and data into the FPGA’s bitstream at the logic synthesis stage. Finally, the complete FPGA project, now containing the embedded DSP image, is compiled to generate the final binary configuration file. This integrated bitstream file, serving as the single software update package with the structure defined in Table 2, is then programmed into the boot Flash memory. During system startup, the FPGA loads this bitstream, configuring its logic and simultaneously pre-loading the BRAMs with the DSP application from the designated ZONE6 and ZONE7 addresses, enabling the DSP to boot directly from the FPGA.

4.4. Fault Monitoring and Autonomous Reset Strategy

To prevent the system from losing control due to software entering an infinite loop or processor exceptions caused by single-event upsets during on-orbit running, this architecture implements a fault-tolerant strategy in which the DSP and FPGA monitor each other and can reset one another. Both the DSP and FPGA continuously observe each other’s operational status. Once one detects that the other is “stuck” or unresponsive, it immediately issues a reset signal to restart the other, ensuring rapid restoration of system functionality.

The monitoring strategy can be realized by periodically exchanging heartbeat signals or performing query-response checks. For example, the FPGA periodically sends query commands or heartbeat signals to the DSP, requiring a response within a specified time window (such as returning status information or a simple acknowledgment frame). If the FPGA does not receive a response from the DSP within the timeout period, the DSP is considered to be faulty (e.g., program runaway or infinite loop), then the FPGA controls the DSP’s hardware reset pin to restart it. Similarly, the DSP periodically monitors status flags or heartbeat signals from the FPGA. If it detects that the FPGA program has stalled (e.g., a periodic flag does not update in expected time), the DSP sends a reset signal to the FPGA to restart the FPGA. The reset chip then restarts and follows the standard power-up sequence, returning to normal operation status.

This dual-processor cross-watchdog strategy replaces traditional standalone hardware watchdog. Compared with a simple hardware watchdog, this solution is more flexible: on one hand, the ckecking period and judgement criteria can be adjusted by software as needed; on the other hand, the detection is not limited to simple timeout events but can consider more health information (such as task execution counts and status words) to determine whether the other processor is running correctly, reducing the likelihood of false triggers. Once a real fault occurs, the system can automatically reset the faulty component in a very short time, preventing fault accumulation which can cause serious consequences. For example, if the DSP program stops unexpectedly, it could leave a thermal control heater continuously on, endangering the whole payload system. This design ensures that an out-of-control DSP is quickly reset by the FPGA, protecting the payload.

Through this multi-layer fault-tolerant design, the DSP+FPGA-based SPC system achieves rapid fault detection and recovery without adding redundant circuits, significantly improving the system’s reliable operating time and safety.

4.5. Mutual Supervision and Anti-Fault Cycling (Anti-Thrashing) Design

4.5.1. Risk of Mutual Reset Loops and the Need for Anti-Thrashing

While the bidirectional mutual reset mechanism between the DSP and the FPGA is a key fault-tolerance feature of this design, it may, under specific scenarios, trigger “ping-pong resets” or repeated reboot cycles if not properly designed. For instance, after the DSP resets the FPGA due to a transient disturbance, the FPGA’s reboot and reconfiguration process requires time (typically tens to hundreds of milliseconds). During this period, the FPGA cannot send its heartbeat signal. If the DSP’s monitoring timeout is set too short (e.g., shorter than the FPGA’s reboot time), the DSP will incorrectly judge the FPGA as faulty and reset it again before the FPGA finishes rebooting. This could cause the system to fall into a vicious cycle where it cannot start normally. A similar issue could occur with the FPGA’s monitoring of the DSP.

4.5.2. Anti-Thrashing Logic Design

To prevent such fault cycles and ensure reliable system recovery after transient faults, we designed and implemented a layered anti-thrashing logic, as illustrated in Figure 7. Its core design principles include: Escalating Timeouts, Limited Attempts, State Degradation, and Differentiated Monitoring.

• Escalating Timeouts and Reset Counters: Each processor (DSP and FPGA) maintains an internal reset counter ($Reset\_Counter$) for the other processor. The initial monitoring timeout ($T_{timeout\_init}$) is set slightly longer than the maximum time required for the other processor to send its first valid heartbeat signal after being reset. Each time one party resets the other, its own $Reset\_Counter$ increments, and the “non-response timeout” required to trigger the next reset increases according to an exponential backoff strategy, e.g., $T_{timeout}=T_{timeout\_init}\times 2^{Reset\_Counter}$. This provides ample time for the reset party to complete its boot and initialization process.
• Limited Attempts and Safe Mode Degradation: A maximum reset attempt limit ($N_{max}$, e.g., 3 times) is defined for each processor. If consecutive resets of the other party reach this limit within a short period, the processor determines that a persistent fault or unrecoverable error exists. It will then:
  • Stop attempting to reset the other party.
  • Clear its own $Reset\_Counter$ and restore the timeout to the initial value $T_{timeout\_init}$.
  • Log a critical error and report it to the satellite platform via the telemetry channel.
  • Enter a predefined Safe Mode. In Safe Mode, the DSP may run only a minimal functional set, such as maintaining basic communication, monitoring key sensors, and powering down non-critical payloads; the FPGA may disable complex processing logic, retaining only essential interfaces and watchdog functionality. Safe Mode aims to preserve the system’s basic survivability while preventing fault escalation.
• Heartbeat Signal Health Check: The mutual monitoring mechanism not only checks for the presence of periodic heartbeat signals but also validates their content. Each heartbeat signal contains a monotonically increasing sequence number and a key status word (e.g., core task execution counter, memory checksum digest). The receiver validates the continuity of the sequence number and the reasonableness of the status word. If a heartbeat signal is present but its content is abnormal (e.g., non-sequential sequence number, illegal status word value), it is considered an “unhealthy” heartbeat. This may indicate that the other processor’s program has crashed while its timer interrupt is still running. For “unhealthy” heartbeats, the receiver logs a warning and may, according to its policy, trigger a soft reset or request higher-level intervention instead of an immediate hardware reset, thereby reducing false triggers.
• State Recovery Mechanism: When one processor receives a valid Safe Mode Exit command from the other (issued by the satellite platform or determined autonomously after meeting certain conditions), or if no new faults are detected after operating in Safe Mode for a sustained period, it may attempt to exit Safe Mode autonomously or under control, re-execute the full boot process, and attempt to resume normal operation.

4.5.3. Design Advantages

By incorporating the aforementioned anti-thrashing logic, the proposed mutual supervision mechanism evolves from a simple “timeout-then-reset” strategy into an intelligent monitoring system with adaptive fault-tolerant capability. It can effectively distinguish between transient disturbances, persistent faults, and normal delays during startup, significantly reducing the risk of prolonged service interruption caused by deadlocks or overreactions. This further enhances the system’s survivability and autonomous recovery reliability in complex space environments. This design ensures the stability and controllability of the entire fault-tolerance process while achieving rapid fault recovery (low MRT).

5. Achievement of the System Proposed in This Paper and Corresponding Experiments

5.1. System Implementation

Figure 8a, b, and c respectively show the PCB of the FPGA+DSP-based SPC system proposed in this paper, the SPC system’s electrical control box, and the complete satellite payload.

The prototype SPC system was implemented using the hardware components detailed in

Table 4. Prototype system hardware configuration.

Component	Model/Parameters	Description
DSP	Texas Instruments TMS320F2812	150 MHz clock, supports XINTF
FPGA	Xilinx Kintex-7 XC7K325T-2FFG900	Rich logic resources Supports multiple configuration interfaces
Configuration Flash	JFM29GL256-E56 (×2)	256 Mb SPI NOR Flash, stores integrated image
Interconnection Interface	Parallel Bus (XINTF)	16-bit data width, address space mapping
System Communication	CAN 2.0B	For commands and telemetry, baud rate 500 kbps
Update Interface	Asynchronous Serial Port (UART)	For image data transmission, baud rate 921,600 bps
Switching Relay	2JB1-910-005	Coil voltage 5 V, bistable state

. This configuration was selected to meet the specific requirements of satellite payload control, balancing computational performance, reliability, and power efficiency. The TMS320F2812 DSP (Texas Instruments, Dallas, TX, USA) serves as the primary control unit, providing deterministic processing for complex algorithms, while the Xilinx Kintex-7 XC7K325T-2FFG900 FPGA (Xilinx, Inc., San Jose, CA, USA) handles high-speed parallel I/O and logic operations, forming the core heterogeneous computing platform. The dual JFM29GL256-E56 flash memory chips (Shanghai Fudan Microelectronics Group Co., Ltd., Shanghai, China) provide the necessary redundancy for the integrated software image, as described in Section 2.1. The interconnection between the DSP and FPGA via the 16-bit XINTF parallel bus enables the high-speed shared memory communication essential for the tight coupling architecture. Communication with the satellite platform is established via CAN bus for command/telemetry, and a dedicated high-speed UART is utilized for receiving update packages. A magnetic latching relay ensures deterministic and low-power control of the active Flash chip selection, a critical aspect of the autonomous recovery mechanism. This hardware foundation enables the implementation and validation of the proposed single-package update and mutual supervision strategies.

5.2. Image Size Analysis

The effectiveness of the single-package update strategy is quantitatively demonstrated through the image size comparison presented in

Table 5. Comparison of software image sizes.

Image Type	Size (Bytes)	Description
FPGA Standalone Bitstream	12,047,189	Contains only FPGA logic and configuration
DSP Program & Data	98,304	DSP application code and data
Total Uplink Data (Conventional)	12,145,493	Requires transmission of two independent packages
Integrated Image (Proposed)	12,047,189	DSP code embedded as BRAM initialization data, minimal overhead added
Reduction Ratio	0.8%	Primary savings come from reduced protocol overhead and single transmission efficiency, with main advantage in management and coordination simplification

. While the integrated image shows only a modest 0.8% reduction in total data volume compared to transmitting separate FPGA and DSP images, the primary advantage lies in operational simplification rather than pure data compression. The integrated bitstream (12,047,189 bytes) incorporates the DSP program and data (98,304 bytes) as BRAM initialization content within the FPGA configuration, eliminating the need for separate transmission protocols, synchronization mechanisms, and version management between the two components. This architectural approach significantly reduces ground operation complexity, minimizes the risk of version mismatch errors, and ensures atomic update of both processing elements. The small size overhead confirms the efficiency of the BRAM embedding technique, making the single-package strategy practical for satellite uplink bandwidth constraints while providing substantial reliability benefits.

5.3. Autonomous Fault Detection and Self-Recovery Strategy: Testing and Analysis

5.3.1. Terminology Definition

To facilitate understanding of the test in this section,

Table 6. Key terms and definitions for the SPC system fault model.

Term	Defination
Fault Detection	The process by which the system identifies abnormal or faulty status, detecting deviations from normal operating conditions through sensors, monitoring software, or self-diagnostic mechanisms.
Autonomous Reset	A mechanism that automatically performs a system reset upon fault detection to return normal operation status, without requiring manual intervention.
Mean Recovery Time (MRT)	The average time required for a system to recover from a fault and resume normal operation. It is typically obtained by averaging the recovery times measured across multiple test trials, as defined in Equation (1).
Weighted Mean Recovery Time (Weighted MRT)	A weighted average of recovery times, in which different fault types are assigned distinct weights to reflect their relative significance. It provides a comprehensive evaluation of the system’s overall recovery performance under various fault scenarios, as defined in Equation (2).

provides explanations of several relevant terms.

The calculation of the Mean Recovery Time (MRT, $MRT$) is defined by Equation (1).

$$MRT={\displaystyle \frac{1}{N}}\sum _{i=1}^N{T}_i$$

(1)

where $T_i$ (i = 1, 2, … N) denotes the time cost for the i-th fault type.

The calculation of the Weighted Mean Recovery Time (Weighted MRT, $MR{T}_{weighted}$) is defined by Equation (2).

$$MR{T}_{weighted}={\displaystyle \frac{{\sum }_{i=1}^N{w}_i·T_i}{{\sum }_{i=1}^N{w}_i}}$$

(2)

where $w_i$ (i = 1, 2, … N) denotes the weight of the i-th fault type.

5.3.2. Fault Model and Test Analysis

To comprehensively account for possible fault types, a fault model must be established. The fault model defines the fault types and their triggering conditions in order to simulate and verify the effectiveness of the proposed fault detection and autonomous recovery mechanism.

Based on the characteristics of this study and common failure modes of payload control systems, the fault model is constructed as shown in

Table 7. Fault model of the SPC system.

Fault ID	Fault Type	Description	Weight ${\mathit{w}}_{\mathit{i}}$
F1	DSP software hang /watchdog loss	Task or driver malfunction, stack overflow, etc.	0.70
F2	FPGA logic freeze /SEFI	Configuration interruption or state machine lock-up	0.20
F3	Boot configuration /storage image anomaly	Requires Flash switching and reconfiguration	0.10

.

Two strategies are compared in handling the faults defined in Table 7:

Conventional Method: A baseline payload control system without DSP+FPGA mutual supervision or autonomous recovery.

Proposed Method: A payload control system implementing DSP+FPGA mutual supervision and autonomous recovery.

Their responses to the fault types in Table 7 are summarized as follows:

Conventional Method:

F1: Only the internal DSP watchdog is used, with a feeding interval of 2 s.

F2: No DSP-to-FPGA supervision and reset mechanism; FPGA faults must be diagnosed and corrected via ground intervention, requiring a system restart.

F3: The DSP OTP ROM lacks supervisory and Flash switching capability; Flash switching can only be executed via ground instructions.

Proposed Method:

F1: DSP and FPGA implement mutual supervision, exchanging heartbeat/watchdog signals, and monitoring key variables (e.g., temperature telemetry) to promptly detect each other’s faults.

F2: DSP supervises the FPGA via heartbeat monitoring and telemetry checks; if anomalies are detected, the DSP autonomously resets the FPGA.

F3: The DSP OTP ROM embeds an FPGA Flash switching program. When the DSP starts in MC mode, the OTP ROM program initiates a timer; if the FPGA fails to start within a threshold, the DSP switches the FPGA Flash chip select and resets the FPGA, completing autonomous Flash switching.

Table 8. Fault injection test cases and expected responses.

Fault ID	Case ID	Trigger Method	Expected Response	Acceptance Criteria
F1	U-F1-01	Stop DSP watchdog feed/DSP hang	FPGA triggers DSP reset	Recovery ≤ 0.25 s; black-box log recorded
F2	U-F2-03	Cut off FPGA heartbeat/set unresponsive state	DSP triggers FPGA reconfiguration	Recovery ≤ 3.5 s; version unchanged
F2	U-F2-05	Inject SEFI 1 (configuration bit-flip)	Automatic reconfiguration	Recovery ≤ 3.5 s
F3	U-F3-02	Corrupt primary Flash bitstream CRC	5 s timeout → switch to backup	Recovery ≤ 8.5 s; rollback logged
Common	U-C-10	Normal operation for 24 h	No false reset allowed	False trigger = 0

¹ SEFI: Single Event Functional Interrupt.

presents selected test cases of the system’s fault detection and recovery mechanism.

Table 9. Comparison of mean recovery times (MRT) between conventional and proposed methods.

Fault ID	Conventional ${MRT}_{\mathit{i}}$ (s)	Proposed ${MRT}_{\mathit{i}}$ (s)	Absolute Improvement (s)	Relative Improvement (%)
F1—DSP hang	3.20	0.18	3.02	94.38
F2—FPGA freeze/SEFI 1	62.80	3.10	59.70	95.06
F3—Boot/image anomaly	122.92	8.12	114.80	93.39

¹ SEFI: Single Event Functional Interrupt.

and Figure 9 show the corresponding test results.

As shown in Table 9, compared to the conventional method, the proposed DSP+FPGA-based system achieved absolute improvements of 3.02 s, 59.70 s, and 114.80 s in recovery times for the three fault types, corresponding to relative improvements of 94.38%, 95.06%, and 93.39%, respectively.

According to the fault modeling method defined in Table 7, and the Weighted Mean Recovery Time (Weighted MRT) shown as Equation (2), the Weighted MRT of the conventional method is calculated as follows:

$$MR{T}_{conv}=0.70\times 3.20+0.20\times 62.80+0.10\times 122.92=27.09\mathrm{s}$$

(3)

For the proposed method based on DSP+FPGA cooperative supervision and autonomous reset, the Weighted MRT is:

$$MR{T}_{prop}=0.70\times 0.18+0.20\times 3.10+0.10\times 8.12=1.56\mathrm{s}$$

(4)

Therefore, compared with the conventional approach, the proposed method achieves an absolute improvement of 25.53 s and a relative reduction of 94.25% in weighted MRT, demonstrating a significant enhancement in system fault recovery efficiency.

The autonomous recovery mechanism broadens the range of faults that can be handled, enabling the majority of them to be detected and corrected in a timely manner, thereby enhancing overall system reliability.

6. Conclusions and Future Work

This paper addresses the technical challenges of on-orbit software updating for satellite payload control systems through a DSP+FPGA architecture. The main conclusions are as follows: (1) The proposed tightly-coupled DSP+FPGA architecture via XINTF interface eliminates additional refresh mechanisms and simplifies hardware structure; (2) the synchronous updating strategy integrating the DSP program and data into FPGA bitstream enables single-package updates for both chips; (3) with the dual-flash redundant boot and cross-watchdog mechanism, the system’s weighted mean recovery time for three fault types is reduced from 27.09 s to 1.56 s (94.25% improvement). Future work includes enhancing intelligence through PHM algorithms, reinforcing security with cryptographic protection, promoting standardization of the architecture, and conducting on-orbit validation in actual satellite missions.